Message to flagged sources without keys can still be improved

[rmol]

Description

We can still improve the explanation a source sees when the system was too busy to generate a GPG key for them.

In translation work for 0.13.0, it was suggested that this:

Our SecureDrop recently experienced a surge of activity. For security reasons, the creation of a two-way communication channel was delayed until you checked in again.

is confusing because of the tense, the vagueness of "security reasons", and using "check in" instead of "log in".

Also:

Please rest assured that we were able to download your submission, and check back again later for a reply.

could more clearly confirm that we received the submission.

Here's my suggestion, to kick off the festivities:

When you created your account, our SecureDrop was very busy and had to defer the creation of the encryption key we need to securely reply to you. That key is now being created. Your submission was securely received, so please log in again soon to check for our reply.

References:

• previous work

[ninavizz]

Thanks for this ticket John, lots to unpack! Ultimately, this flow needs to go into user testing to refine the message. Much of the content in the Source Experience is problematic—for exactly that reason.

I'm not worried about "Log In" vs "Check In" and separately want to change login it to "Check In" eventually, anyway, since the spoken-to interaction does not match common mental models of a login/signin. But, again—that needs user testing to validate, tweak, or invalidate.

We're also intentionally vague around "security reasons" because it's important to not get all techno-specific with users... because we expect many to not know what a security or encryption key is. Imposter syndrome is a bigly consideration.

Anywho—this is a great example of the importance of testing stuff for comprehension before it gets deployed. Really looking forward to improving this, and all the other messaging in SD... but it's not a quick nor easy process.

[eloquence]

Deferring further work on this for now until we've had a chance to investigate if we can get rid of entropy checks entirely (#1584), which would enable us to remove this feature.

[ninavizz]

Let's tackle this in #4967, or better yet—kill the entropyfail schtick altogether via #1584 !!

[eloquence]

Closing in favor of #1584, which we may be able to address as part of the Focal transition.