We would like to get some feedback on the new encryption passphrase workflow. It is deployed on the QA satellite. Please give it a try and share your thoughts with us.
What has changed:
The encryption passphrase for the file browser is set on the project level. Changing buckets doesn’t require entering it over and over again.
Known issues
Changing the passphrase is possible. We are missing some kind of tool tip that explains to the customer how to find the menu for changing the passphrase. It is hidden under the project drop-down menu.
Tradeoffs
Logout or switching projects will clear the passphrase. In the original design, this feature was designed to be opt-in. The engineering team pointed out that the most secure way to store the passphrase would be inside the browser object like we are currently doing anyway. That removes the opt-in idea because as long as the file browser is open the passphrase is stored in the browser object regardless of customer choice. Opt-out only means it gets cleared earlier.
However, there is one downside. Since we don’t persist the passphrase in the session or local storage, it will also be cleared by pressing F5.
Sounds good in principle, but a lot of it would depend on how the UX is implemented and what information is provided alongside it. I’d love to check it out if it gets rolled out to a validation satellite.
It will help prevent users from thinking the pass phrase is tied to a bucket for some reason. The old UX kind of suggested that (in some cases even explicit said that).
The new UX is available on the QA satellite. Just imagine that the UI gives you a hint about where the menu for changing the passphrase is located (see the known issue section).
So it looks like most of the UX remains the same, still suggesting the passphrase is somehow tied to the bucket. The onboarding flow has you create a first bucket and set a passphrase for that bucket. That context still doesn’t make sense to me since the passphrase is tied to objects (or your session), not to buckets.
I also noticed that in the manage passphrase screen you have options to create a new passphrase or switch passphrase, which is essentially the same thing except the first allows you to generate or enter one, while the second only allows you to enter it. Since you’re not creating anything, just switching the passphrase for your current session, I would suggest merging these options under the switch passphrase terminology.
When you first sign up, the box says that each bucket should have its own passphrase but then when you create a new one it doesn’t ask you for a new passphrase. So I’d think the wording needs to change on the new user 1-2-3 step boxes to reflect the new concepts.
You could also put on that 1-2-3 step process that if you want to change the passphrase, you can via the project menu dropdown, but if I had to guess independently it’d be in the “access” section under bucket default passphrase or something like that.
If you want to be on the safe side you can do an uplink ls --recursive with and without --encrypted. If they both show the same number the message should not show up. If the number is different it would mean you have files in that bucket that can’t be decrypted with the current encryption key.
The UI should make that comparison but unfortunately, there is a bug. After fixing that bug I would expect the number to change. If it drops to 0 the message will disappear. Even if we call it a bug it doesn’t mean that fixing it will remove the message entirely. You might have a few files with a different decryption key without knowing it. That is why we implemented that message in the first place.
I would expect that fix to get deployed next Monday but lately, we postpone the release more often so let’s say sometime next week to be on the safe side.
