Some apps will need this info so that they can copy (send datamap address) to elsewhere. And all those sort of utility functions.
Rather than push this out to the network, just have permissions to allow/deny this and the permissions can inform the user so they can make informed decision.
So then your image display APP would normally be denied, but your utility APP would be allowed by the user.
This is different to accessing the datamap. Apps do routinely have the datamap address (this is the XOR address/name for Immutable Data / and Mutable Data).
So there are two issues, knowing the address of the data map which is useful for many apps IMO, but could be shielded via a handle.
Secondly, being able to access the content of a datamap and see the chunk addresses directly.
I think the only way to hide this from apps securely is to push that knowledge away from the client onto the network. Otherwise, you can’t stop an app bypassing the APIs and looking directly at what is on the client (through various means).
We would need APPs to access files through filenames and the client libraries (or network side using your idea) then access the datamaps corresponding to the file name.
This is because once you have the datamap address then you have the file (unless its doubly encrypted with another key)
Once the APP has the datamap address then it can message that to the APP writer and the files is exposed.
So it seems to me we need to make APPs access files via a filename or identifier instead of the datamap.
Do this by permissions. and then only special utility APPs should be given permissions to access this information.
Yes but then that increases the state kept by the network by a significant amount and maybe too much. Not sure the balance here that would work well.
How are you going to check for this? If we consider only client side web apps, then you may be able to lean on the web browser sandbox, but if it is a standalone app, all bets are off - it becomes way beyond the scope of what you can expect SAFENetwork to influence.
Yes, you can set up permissions at the OS level for this sort of stuff, but unless we have SAFEOS or some such, this is beyond the reach of the SAFENetwork client.
If you haven’t checked out that link that Hunter provided yet, definitely do. It gives a great example of object control in the context of giving a friend access permission to her car with limitations. It’s a great example of the capabilities. Really cool stuff!
A SafeStore repository for trusted apps that have been vetted to not be sneaky is a start.
Yes, exactly. I don’t think you necessarily need a SafeOs though. It’s probably better to presume the OS is rather unsafe and block/report unsafe behavior. A standalone SafeWall app to block sending packets to all non-safenetwork ip addresses except those trusted ips you explicitly allow such as a network printer is something I’ve been thinking about lately.
Just a side comment or two.
I don’t think it is feasible to hide the XOR address of a file / datamap because it breaks the content addressing aspect for apps, and means you would have to provide an intervening addressing scheme, an extra lookup, with several extra hops every time you access a data map.
But I don’t think you necessarily need to do that because, while…
That’s the case for public files, but I expect that’s both less bothersome - since we chose to make them public - and not that worth doing for an attacker, because the data is public anyway.
Private files are double encrypted, so discovering the data map is not an issue unless the app has also obtained and shared the key. And if that is happening, I think we have a much bigger problem.
@neo what do you think, does that stand up?
Is that correct? I have not kept up with that part, but this doesn’t sound right.
I know the user or APP could encrypt the file before self encryption.
But a lot was made of dedup which dedup any file whether public or private.
You may well be right. It seems like an important question!
@viv are files in private containers (eg _documents) to be kept private just by encrypting the container to protect their xor address, or will the files themselves encrypted, such that just knowing the xor address of a private file does not give you access without the decryption key?
Are all our private files held in containers? Or just the datamap addresses.
ah soz mark I havent looked into this in a while, so will prolly be relying on @nbaksalyar or @marcin or some1 in frontend to clarify the specifics of what is happening for these containers by default from SCL or frontend libs.
With private containers the container itself is encrypted gives the option of having encrypted entries. Further security, by encrypting the files as well, must be done by the user or app. Reading more closely, as for the question about double encryption, encrypting the file content before self-encryption does not provide further security, but you can encrypt or not encrypt the data-map.
Edit: made some corrections above so as not to be misleading.
So to check I’ve got this…
_publicNames, _documents etc)This ensures deduplication works on chunks relating to the same file stored more than once, whether public or private.
@marcin is that correct, and is encryption of the data map handled in a similar way to container entries?
Or a better question would be, how feasible is it for a Web app obtain the keys that are needed to decrypt a data map, in order to leak both the XOR address of a private file, and the means to decrypt its encrypted data map?
So are these entries the files themselves or the datamaps to the files.
It means the key and value of the entry are encrypted, but if you give an app access, it can decrypt them and will know both.
Once the file undergoes self encryption it will produce encrypted chunks of Immutable data which due to the entropic nature of encryption is likely distributed to different places in the XOR space. Even if you somehow manage to get all the chunks there’s no way to reconstruct the file. You would need the keys that encrypted those chunks. This is what a DataMap is. It keeps the encryption keys (which can be imagined for simplicity as some deterministic transformation of pre-encrypted plaintext chunks of the file) and the name of the encrypted chunks. You read the DataMap to fetch all the encrypted chunks, use the keys there to decrypt them and then use the order there to reconstruct the file back.
So anyone with DataMap can read the file. If you want the file to be public, let the data-map be public (so still do self encryption for the advantages of de-dup etc.), if you want the file to be private, encrypt the data-map.
Where you store your public/encrypted DataMap is upto you. For e.g, if you put the DataMap in a private Container (MutableData) then it’s going to be encrypted according to the parent’s (Container’s) logic along with other stuff in the Container. If you put it in a public container, anyone with access to the container can read it’s contents one of which might be a data-map and eventually get to the file.
Thanks @ustulation. So an app that is allowed to access a private container will have both the address of the datamaps to files held by the container, and access to the encryption keys necessary to read/decrypt each map and its file content?
The context here is to understand what needs to be leaked by an app in order for it to leak private data.
The point of these questions being that, if an app has both the address and file decryption key, that’s much easier for it to leak than if it had to decrypt the file content and send the whole file elsewhere (with malice).
So can you just confirm whether it not a malicious app can obtain and leak the key as well as the datamap address of each file, once it is given read access to a private container. Thanks.
@ustulation Aside: for testing SAFE Drive, is it currently (alpha 2) possible to access any private containers? I’ve tried the standard names but they didn’t work so I’ve assumed they are not yet created in the account.
You need to leak the datamap to leak the file. DataMap is just a structure with records. You can further put it as an unencrypted ImmutatbleData into the the network and put the name of the ImmutData into a private container thinking you are safe, but as you can guess you aren’t. Sure no one can read you private container to get the name of the ImmutData representing your data map. But anyone by chance can come across that datamap anyway and then use it to read the file.
So if storing datamap inline in a private container, you don’t need to encrypt the datamap separately as it will be encrypted along with other stuff in that private container as usual. If storing only the name of the datamap in a Container, make sure that the actual datamap is encrypted with something.
A bad app needs to either make the keys of the private container storing the datamap known or needs to make the keys used to encrypt the data map known to leak the files. All in all, protect data map to protect files.
Thanks.
This is the issue I’m trying to establish. So it is possible for a malicious app, once granted access to a private container to leak the files through a low b/w channel, because it can obtain the datamap decryption key, as well as the datamap address? Ie it doesn’t have to copy even the datamap, just a couple of strings.
Just to be absolutely clear! 