Improve UI on Download Locked Box page

[chmurson]

Context
After all parties experience box creation, they are navigated to download locked box page, where they can download file with their box.

There is small delay between leader clicking the button and is navigated to download page

What?

• Keep connection open on that page for Leader an Follower (already done for Leader with milestone Test be ci monorepo fixes #2)
• Record who:
  • has downloaded their box; display that feedback to everyone
  • has received their keys; display that feedback to everyone
• Enable download button for all participants only when all of the participants has received their keys.
• make leader who clicks create button Either
  • to navigate to download page without a delay
  • to show loading button and disable other UIs elements on the Create Box page

[tomusdrw]

Not sure if this is relevant here as well, but just transferring the Box and the Keys can take some time and it might be good to have that information somewhere.

Ideally leader would coordinate so that everyone's UI changes to "Download" only after all follows get their keys.

We could use the timer to send like 90% of the keys during the timer and then only send the last (random) 10% of the file when it finishes.

[chmurson]

Not sure if this is relevant here as well, but just transferring the Box and the Keys can take some time and it might be good to have that information somewhere.

Good point. Initially I thought about only visual feedback about participants downloading their files, but feedback whether each participant received or not the key is also important. I think your comment is relevant here.

[added here]

Ideally leader would coordinate so that everyone's UI changes to "Download" only after all follows get their keys.

Sounds good. That would ensure the file is downloadable only after everyone has received their keys.

That could potentially protect from case when box file is downloaded, but can't be unlocked later, because some of the participants haven't even received their keys yet.

[added here]

We could use the timer to send like 90% of the keys during the timer and then only send the last (random) 10% of the file when it finishes.

Not sure what would be benefit of that ? Okay I get it, so to make it safe. If follower cannot download the box file he shouldn't have his complete key just yet. I feel like this particular point could be a separate task. [not added here]

But does it really matter ? If a follower gets a complete key, but we won't enable the donwnload button isn't a problem I believe ? The follower - even he cracks the apps code to get the key anyway - he won't be able to unlock it themselves anyway.

Blocking the download button to me is a UX improvement -> telling user shouldn't download the box while it's clear it won't be possible to unlock it.

[chmurson]

@tomusdrw please look at the last comment to the last part ☝️

[tomusdrw]

If you mean sending the box/keys during countdown, then it is an extra (and optional) feature. No need to focus on it right now.

Just disabling the button UX-wise is not sufficient. We should assume that in case of a malicious actor they will use every possible attack vector, including altering the application code (changing button state from disabled to enabled is actually also pretty trivial in dev tools :)). So if that feature is going to be implemented it needs to be done securely. Sending X% and then (1-X)% at the very end seems safe enough (with some wise pick of X to prevent bruteforcing).

The follower - even he cracks the apps code to get the key anyway - he won't be able to unlock it themselves anyway.

That's not true. If the follow get's "promises" for all the required keys, we transfer them after the countdown starts they will be able to unlock the box even though the countdown hasn't finished. This should not be the case.

[chmurson]

If you mean sending the box/keys during countdown, then it is an extra (and optional) feature. No need to focus on it right now.

Just disabling the button UX-wise is not sufficient. We should assume that in case of a malicious actor they will use every possible attack vector, including altering the application code (changing button state from disabled to enabled is actually also pretty trivial in dev tools :)). So if that feature is going to be implemented it needs to be done securely. Sending X% and then (1-X)% at the very end seems safe enough (with some wise pick of X to prevent bruteforcing).

The follower - even he cracks the apps code to get the key anyway - he won't be able to unlock it themselves anyway.

That's not true. If the follow get's "promises" for all the required keys, we transfer them after the countdown starts they will be able to unlock the box even though the countdown hasn't finished. This should not be the case.

I didn't got initially you mean to send the keys before the countdown completes, but now after I re-read the original message I don't know how I missed it :) In that case, I agree, please forget about my initial question.

Somehow I thought you want to send part of the keys after timer completes, and only after all partiall keys are send, to send the remaining parts of partial keys. This sounded like a nonsense to me, but now I see I simply misunderstood. :)