Securedrop: Detectable system problems should be surfaced in the Journalist Interface

[zenmonkeykstop]

Description

SecureDrop maintenance relies on administrators paying attention to OSSEC alerts (or the lack of them), messages from the support portal (if the organization has been on-boarded), and FPF social media and blogs. If they're not paying attention, their instance may be usable but in an unsafe state:

• scheduled updates may not have been applied
• OSSEC may be misconfigured, or communications between the Application and Monitor Servers may be broken
• general system configuration may not be correct (bad file permissions, non-grsec kernels, apparmor etc)

If the instance is in use, journalists may be checking it regularly. Displaying warning messages in the journalist interface about system problems and encouraging them to contact their instance admins would increase the chance of those problems being fixed, and avoid giving false confidence in the security of misconfigured systems.

One simple check would be to compare the installed app-code version versus candidate versions. Another would be to test for the kernel type. A more general configuration healthcheck could also be done on a scheduled basis, with the results displayed in the JI after login.

User Research Evidence

Timeliness of responses to urgent communications to admins from the FPF would indicate that there's a need for extra messaging. INstance admins have other duties, and it may not be reasonable to expect them to always be on top of things.

As this is a feature that involves a front-end change intended to put the wind up jounalists who see it, UX and design input on how to do that effectively would be valuable.

User Stories

As a journalist, I'd like to be assured that the instance that I'm using does not have major problems, and to be informed if it does.

[ninavizz]

Ohai... commenting to get this on my radar! Relevant to https://github.com/freedomofpress/securedrop-ux/issues/29 and https://github.com/freedomofpress/securedrop-ux/issues/28

[zenmonkeykstop]

Thanks @ninavizz - input appreciated. I'd been thinking of this for the browser-based JI, but it could definitely be considered for the Qubes client too.

[ninavizz]

Sweet! Yeah, I'll make a JI recco, too. A side-proj of the Workstation has been reconciling all of the language between the two experiences, so I gotta revisit some of it, anyway!

[eloquence]

Per sprint planning today, at minimum, we'll want to implement a Xenial-specific message; a more generalized approach would certainly be welcome as a stretch goal. I've added #4027 to the sprint backlog, and @zenmonkeykstop has expressed interest in potentially pushing beyond those narrow requirements as time allows.

[ninavizz]

I'd actually love to revisit this Issue, too, with a defined set of messages/icons to the bullets @zenmonkeykstop identified, above. It seems like a great start to creating a concrete set of defined messages w/ rules for an existing-product styleguide.

The Xenial issue in ...027 is a great start—and as we're considering specifically that one messaging scenario it'd be great to evaluate other alert scenarios for that area, too. Happy to discuss further @eloquence if so desired.