This is a suggestion to implement a way to allow one party to write new files to a maidsafe account, without being able to view or edit the contents of the account, to advance personal security.
This would allow a setup where new information such as recently taken photos, videos/audio being recorded, or phonecalls could be securely backed up automatically from a phone signed in with this write-only password. The information would be protected from everyone, potentially even the owner of the account if they choose not to memorise their own password (which would protect the information from coersion). No-one could be sure that information has been written to the account as the network wouldnât disclose when the account becomes full, and there would be no option to view the recently uploaded files, providing plausible deniability.
Hereâs an extreme hypothetical case in which this might be useful: Someone is filming a crime being committed. The criminal takes their phone, deletes the file, and smashes the phone. Part of the video is then stored on the network, invisible to all but the owner, who can then present it as proof of the crime. If this became well-known, anyone being filmed would know that they canât necessarily silence the witnesses.
is a problem . How will anyone be able
to know , access & view the content ?
Such proof-surveillance would also need
to record & upload its files immediately ,
as real-time as possible to be useful .
I get the idea of write-only in order to protect all details & the fact ,
therefore , if such would be possible , a mechanism pointing to
the read & replay option of the files would be really necessary !
I think the simplest way to accomplish this would be an app that (a) self-encrypted the file, (b) sent a message to another account with the data map, and then (c) deleted the data map from the account so it couldnât be recovered if someone else got the password. Or, of course, one could do this directly without an app. Might be easier that way, but Iâm sure an app could automate it to some degree.
Whoever has the main password would be able to view it. So, for instance, the phone could be logged in with the write-only password, and the full access password could be stored partly on a bit of paper at home.
That makes sense, so the write-only password could be replaced with an âaccept listâ, which the hosting account uses to determine which accounts it would automatically accept files from. Would that work with real-time streams?
why so complicated? writing to the network is a fundamental thing. just write your file to the network and send a message or tag the object you wrote to whom it should be sent or who should or could subscribe to it. this is no different from messaging or elementary stuff like that. insert into network and send information about it to your destined party.
There would need to be some way for the recipient to automatically take ownership of the file for this to work, otherwise it could be deleted without the main password.
If you had an APP on the account you want âwrite onlyâ then it could do the functionality you want rather than write it into the SAFE network code.
2 options.
Easy option and maybe not secure enough for you - Replace the launcher with another that will not reveal what is stored on that account. So you start that version of the launcher and log on. Store away and if some one gets your phone while recording they cannot see what you wrote to the account. If they start the normal launcher than they would need the login credentials.
@fergish sytle. - Have an APP that records the files/stream and gets the chunk addresses and messages them to another account then discards the chunk address so that its not in that account ever. The messages can be sent to any account you choose. Then a complementary APP is run on the other account (real time or later) and it takes the messages with the chunkâs addresses and reconstructs the file/stream.
If you use 1) then if they beat the credentials out of you then they can see what was written by running a normal launcher.
If you use 2) then you have a lot of flexibility as to how you handle the files/streams. You could even send the chunk addresses to multiple accounts (say all the newspapers or your family/friends) and have further protection.
SAFE doesnât have the concept of ownership for immutable chunks (file storage). If you have the datamap (list of chunk addresses) then you have access to those chunks. Seeing as the chunks are immutable then knowing their address in order is everything needed to read them.
Note: if one tries to randomly find chunks and read them then they are out of luck. You need 2 other chunks in correct sequence to be able to decode the one chunk. And to access 3 chunks randomly and they be in sequence is inconceivable with any foreseeable technology. Random 512 bit addresses would be difficult to even find a chunk let alone 3 in the correct order.
Ideally this wouldnât need to be written into the SAFE network code, but could the same functionality still be achieved in real-time when the recipient account isnât logged in?
Automatically deleting the original file wouldnât necessarily be turned on by default (I canât think of much use for a feature like that), but I guess modifying it slightly to give it a different chunk address would provide plausible deniability. But without a concept of ownership, how does the network decide who to charge for storage, or whether to stop storing a chunk?
Yes, messaging does not require the recipient to logged in. Just like email, the recipient collects the messages when they want to, or an APP does it for them. So the APP would look for messages from the corresponding APP and process those messages building up the files/stream again. This can be in real time as the chunks are written or done after the fact later on.
You would need that so anyone accessing your account (bashed out of you or you complying) does not see any files/streams of whatever you didnât want them to know about.
Yes you could swap the order or change addresses in a reversible way
You are charged as you âPUTâ the chunk, and if you PUT a chunk then you are the one who pays. There is no ongoing ârentalâ or âchargesâ so no need to know who put the chunk after it is written. Actually this is one of the important security/anonymity features of SAFE.
Having the datamap (ordered list of chunk addresses) gives you the ability to read the chunks, which at this time all that you can do to the chunks.
Thanks for the clarifications. I canât help but think that keeping every unreadable file and charging for each new upload (including updating files) will end up costing a lot, but I guess thatâs something for a different topicâŚ
So, for this automatic silent backup system I guess we just need someone to write it into Replicant or something.
You only pay for each chunk uploaded once. So you only pay for the actual data you upload. Only other put charges are any SD objects created for First message sent (the outbox creation) and any directory SDâs that you create (if any). I am not sure if there is a put charge for the datamap.
Basically there might be one extra put charge on top of the charges you would have had to upload those files anyhow.