Encapsulated accounts for plausible deniability

@draw posted something about a 10-year penalty for refusing to decrypt data in Australia.

A sockpuppet account, that you forgot to update since two years ago when you cleverly set it up, will not save you at that point.

Encapsulation would be a way to log in to a master account which would automatically log you in to your encapsulated mini-accounts. APPs would logged in to their respective mini-accounts, but more mini-accounts could be used parallel to one another. This would remove the need to switch between accounts but it would ensure your data between sensitive and not very sensitive APPs would not get mixed.

If accounts could be encapsulated, you could give out the password for your “innocent” account with all your (not too sensitive) conversations with your wife and kids and coworkers. As you have been using this mini-account (albeit alongside your more sensitive mini-accounts) until the previous moment, so this would give your adversaries something up-to-date to look at without incriminating you.

It’s a GUI related suggestion so it doesn’t affect the deeper design of the network or the core.


The difference between that and what I suggest, transplanted into the crypto wallet context, is that you would use both accounts with a single login. Whenever you would have to pay a small amount, your wallet would select the account with the small money, and whenever you needed to transfer a large amount, it would select the secret account with much money.

This way, if somebody forced you to reveal your password, you could give them the one for the small account. They would see an account with numerous recent transactions, so they wouldn’t have a reason to doubt your sincerity.

There has been discussions about this in the past. Even as far back as when the login to the network was different and required an extra field of a PIN

The idea raised then was that different PINs would give you different accounts.

If you look at what an account is then I think the idea of multiple accounts with varying degrees of access is possible and definitely desirable as indicated by the discussions in the past.

An Account contains a series of IDs for your account and some other data so that you can access your private files.

It would be possible to have multiple accounts that have certain IDs shared and certain private files shared too.

  • Account 1 could be your master account with everything or most things
  • Account 2 could have the IDs used for family interaction (emails, forums, etc). It has the datamaps for private files that you want in this account
  • Account 3 could be for work related IDs & private files
  • Account 4 and so on.

Then perhaps have an APP that can allow you to send to other accounts the IDs, datamaps, etc that you want for that APP. When you log into another account then the APP sees newly transferred IDs etc and adds them to the account.

This way you can give the authorities the account details of the particular account you want.

This is a method using separate accounts but in a way that shares parts with other accounts. And needs you to switch between accounts but only when you want access to things the current account does not give.

I do like the encapsulated accounts

One way might be to have the separate (shared) accounts as above but the client allows you to log into another account at the same time.

There is no technical reason this couldn’t be done and would require a better client than is currently used. And as you say this is all client side coding.

An account is just a collection of data that defines the data/IDs held for the user. Without requiring changes to the core system then the “mini-accounts” would be accounts in their own right. Just treated differently. The login process just identifies the account data address and the pass phrase to decrypt that data object. Thus mini-accounts can be the same thing and used as normal accounts or a mini-account with a client that allows it.

My concern is that if this is available as “mini-accounts” then the police simply asks for the details of your mini-accounts (as part of the scripted questionaire they’d have) and we are back at square 1. If you treat the other accounts as actual accounts and the client allows multiple accounts to be accessed together then the police can only ask if you have other accounts and since they are unrelated (login wise) then you can deny having them.

The beauty of SAFE is that they cannot prove you have other accounts unless you tell them somehow (directly or in online-interactions, etc)


Yes, that’s how I see it. The mini-accounts are just login details for other regular accounts, stored in the main account.

As you said, the mini-accounts would be just regular accounts. You could also have another mini-accounts within one of your mini-account, but nobody would have to have mini-accounts.

Exactly. The reason behind this suggestion was that it’s unlikely that users would put an effort into maintaining a fake account for just in case. However, if they would keep using their relatively insensitive account while using their more sensitive accounts, the insensitive account would always have enough and, which may be the more important thing here, recent enough activity so as to not raise suspicion in an attacker, may it be the Australian government or a street thug.

It would be a nice touch for the GUI if one could switch to “safe mode” by entering a panic PIN or finger pattern or whatever the GUI used for locking the interface. Maybe even without that, after some time of inactivity.


Which is why I suggested sharing certain IDs/files/etc between the accounts, so if I post to a family forum from the main account then in effect I’ve posted from the family account since they are in fact using the same ID that is being used for that particular family forum.

So then once setup (with Aid of an APP) I can use any of the account with a particular ID and it would appear I used both accounts. So then the family account is being used even though I never logged into it.

I understand what you are saying and I hope that someone creates a client that allows for opening multiple accounts at the same time. And then if you create a new ID for some forum/blog/whatever then it can be stored in both accounts at the same time (if requested). Then when you just log into either account it appears that the ID has been used. Enabling plausible deniability.

The only thing we don’t have at this time is an APP to make this process easy and/or a client that can log into multiple accounts at the same time.

Yes I hope this is done and I’m sure it will be done. Fork the client and add the mods to do it. Then anyone can use that client rather than the stock client.


It is sad that this comparison can be made.


I may be a bit behind on how things work. Do APPs use bearer certificates? Then the solution would be as simple as sharing the certificate that was created by the less sensitive account with the more sensitive account. Am I understanding you correctly?

In this case, the OP is already solved and it just needs some exposure in the GUI, including switching accounts by entering the “wrong right” unlock code.

Unsure at this stage how that might be implemented. The XOR address of the APP is going to never change since its immutable file. And updates to the APP obviously will be a new XOR address since its a new file. People can run the old version or the new version if they trust it.

Its not the APP that is important. It is the ID or IDs you use with the APP for writing data objects on your behalf. So for a forum APP the APP will use the ID as your “identity” on the forum. Likely to have a friendly name etc associated with the ID.

Thus its not the APP but your IDs used

Yep, but rather than lock/unlock code, its more the account you tell them about.

Sorry, I think I wasn’t clear. What I meant was, when I run an APP, it would use a bearer certificate (a piece of signed document) to authenticate (prove it’s acting on my behalf) and to authorize (prove it has the necessary rights for the action, for example, write access or read access or both) access. The other way would be using a username and password, for example.

When APPs write data for you, the APP has to be authorised in the client to do so. This is the way APPs effectively get what you were asking. There is no certificate for APPs.

So if an APP writes data using your ID, it first had to get permission to do so. This permission is given via the client and without it the APP cannot write (PUT data).

My question is about how that permission is expressed. The technical details of how an APP proves itself worthy. Yes, the APP has to present my ID, but it also needs to prove it has the rights to use that ID and I think that means what we have here is a certificate signed by the ID.

Or am wrong and APPs connect through a separate client? I thought Safe moved away from the separate login process model because that’s not universally doable (iOS, for example, doesn’t allow background processes unless you’re some sort of deity).

EDIT: Talking about bearer credentials reminded me about something I saw recently. I started a separate thread for that: Bearer credentials with caveats for distributed authorization

Yes the client is the PC side code that communicates with the SAFE protocols and is built into the browser at the moment but can be standalone

I see. I suspect the client is a library, right? So, it can be directly linked to APPs, but the browser is the only such app currently. At the same time, the browser can serve as an API bridge between that library and Javascipt or WASM APPs. I’m just trying to make sense of how things work, please feel free to correct if I’m wrong.

1 Like

For a high level overview of how it all fits together see https://primer.safenetwork.org/ especially chapters 3 - 6.

1 Like

Thanks for that! I found the answer in chapter 10. It seems I was right about how it works:

In a similar way to the familiar OAuth process, the application sends a request using the library for authorization. When the authorization is approved by the user, the application receives a token which is used to connect to the SAFE Network. Authorization is achieved via an application call to the Authenticator, which is currently bundled with the SAFE Network browser Peruse.