pddb default should display default, and optionally allow pointing to an alternate basis (like .System) for the next write operation?

[spoelstraethan]

If you don't close out all your secret bases you can't write additional innocuous data to .System like a to-do item or something else non-secret, which if you have a lot of bases results in a LOT of retyping of passphrases.

I was sort of expecting pddb default <some-basis-name> would change the default so that the next item created would end up in that specific basis. Since it is possible to use the Precursor without any bases (I think FIDO2 and U2F still work, not sure about resident keys, probably should as long as you have a PIN set).

Failing that I tried to do a pddb unlockbasis .System but it didn't like any of my PIN attempts, neither the root nor the unlock PIN worked, and I didn't have time to try the full BIP-39 of the null key......

Was inspired a bit by the discussion here, https://github.com/betrusted-io/xous-core/issues/194#issuecomment-1303461104

[bunnie]

Interesting. So would the argument for the workflow look something like this:

For reads:

• Always return the most recently opened Basis in the Basis union view that holds the desired key

For writes:

• Default to writing to .System even though multiple secret Bases maybe open
• Only write to a secret Basis if it is explicitly specified by a flag that specifies the Basis

Currently, the behavior of read and write are symmetric, i.e., you write to the most recent secret basis, and you read from the most recent secret basis.

Your proposal is to make that behavior asymmetric: read from the union view, write by default to .System unless otherwise specified.

This would punt the correct storage of secrets up to the user interaction/application layer, where the application must specify a secret basis in order for it to be used on a write.

I see the logic behind your proposal, if this is the case, but it does break a principle of plausible deniability. Namely, an application can never fail to operate if a secret Basis is missing. If writes specify a secret Basis explicitly, then if a secret Basis goes unmounted while the application is running and then the write tries to put data into this secret Basis, what happens? Popping up a dialog box would give an obvious "tell" that would defeat plausible deniability. The analogy I always think of in a conventional computer is you often have a "File->Open recent files" menu item, and if you unmount a secret volume the volume handle will still be in that list. If applications now have to explicitly track secret Bases to use them, they effectively retain a "File->Open recent files" list internally, and that can be used to disclose the existence of a secret Basis.

That being said, in practice I may be arguing about an edge case that is irrelevant. But at the very least the logic behind symmetric, transparent read/write operations is to ensure the application does not fail in the case of secret basis gone unmounted.

The counter-argument is that the "read" data on vault for example has to be refreshed when a secret Basis is unmounted, because you want the entries in your UX to disappear for entries that are no longer available. So we already have to support some kind of a signal that can be used to flush the "most recently open basis" list inside the application logic. The difference between the two cases though is that the list of keys that are secret in the UX don't know the name of the Basis it came from, whereas the "write" tracker actually has to keep track of a secret name, which may betray even more significant secrets.

[spoelstraethan]

My suggestion isn't defaulting to System for everything, but allowing to override the write destination from the most recently mounted basis to another write target explicitly by running pddb default <another already mounted basis name>.