Warnings on source interface are not clear enough

[redshiftzero]

Description

Based on feedback from a user test documented on our community support portal:

the security warning with a purple background was entirely ignored and she did not even notice it was there, mistook it for a decoration of some sort

These warnings are displayed in each of the following situation:

• Source has not set the Tor Browser security slider to High
• Source is not using Tor
• Source is using Tor2Web

We could make this notification stronger, for example the notification could actually impede a source from proceeding, e.g. one that they should have to "X" out before going to the submission step. Obviously, we need to balance this with scaring people away, and we should carefully consider anything that would put up roadblocks in front of sources.

If we continue to hear this feedback in user tests, then we can make modifications. I would suggest there should be a quite strong notification for not using Tor or for using Tor2Web such as the one described above for the likely very small subset of users able to access the source interface without using Tor Browser. There should be a less strong notification informing them to set the Tor Browser security slider to high - but strong enough that the source reads it.

User Stories

As a SecureDrop source, I want to be clearly alerted if there is an important step that I should be taking for security reasons.

[redshiftzero]

Just heard this again in two user tests at the Aaron Swartz Hackathon 2017 - users didn't notice the warning. They said that it 1) was too small and 2) the color did not stand out enough. After reading the language on the warning, specifically the "or ignore this to continue" one user said that it didn't seem that important and he thought it was still probably safe to proceed. These criticisms also apply to the security slider warning.

[huertanix]

Assuming we don't have any use cases where a user would need to use a medium or high Tor Browser security setting, would there be any way to disable and visibly "gray out" the landing page buttons (Submit Documents, Check for a Response) with JS so that they only work when JS is turned off at a higher security setting? The click action on each button could also be set to CSS-pulse the background color of the warning message to bring it to the user's attention.

[KwadroNaut]

Because @redshiftzero asked my 2 cents here: I find it very hard to strike the right balance; enabling without endangering users. Educating without crippling. I agree about the warnings that aren't displayed (#2617), that are too small and in a nice decorative setting should be redone. It would probably make sense to test, use mocks, and then chase all the different pieces that are in use of such an overhaul I like @huertanix' ideas.

[redshiftzero]

Recently, @harrislapiroff and collaborators asked this question for https://securedrop.org and came up with the following:

It's certainly stronger and thus hard to miss. It's not quite as strong as graying out/disabling the buttons with JS (this is doable and an interesting suggestion, the only thing is that it's quite heavy handed). How about we also use a similar approach on the source interface?

This ticket is a higher priority to address, because Brave has Tor tabs in beta. This is a cool feature, however they do not yet provide the same level of protection as Tor Browser. Brave does show the following warning, which describes that users who rely on Tor for personal safety should use Tor Browser:

Sources might miss this, and as such we should more strongly discourage them from using Brave's private browsing tabs with Tor in favor of Tor Browser. Brave users currently get this very subtle warning when they use SecureDrop:

[huertanix]

I think a new securedrop.org style warning would definitely be more noticed than the purple band for the security settings warning. Maybe we could try it out, and in my / the UX team's observations we can report back on whether users are reading the warning and changing their settings.

[huertanix]

Adding some input from sessions training journos through the process of going through a source's submission flow: No one noticed the purple band, nor did anyone read the warning or change their settings.

[ninavizz]

Just a friendly note: I want to caution against knee-jerk responding to "yell louder, over there!" impulses when users don't respond to security measures as we'd like them to. Human cognition and human behavior are not binary problems to solve for.

Similarly: observing users in training sessions is very different from usability testing. Ideas need to get shown to users in a "natural use" scenario and evaluated against the user's own, un-guided responses to a low-fidelity interactive experience, before they get built as code. Iteration needs to happen before the investment of dev time is made, to meet the quirky needs of shaping human behavior.

It is a rare and wonderful opportunity that FPF has a training team that works with 2 of our 3 user types. Their insights need to be more holistically collected to be put to work for users in what's designed, built, and deployed. Observations from training sessions tho, are not a replacement for structured user studies. Especially considering the risks and counter-intuitive information our users come up against, when using SecureDrop.

Depending on how often training sessions and/or offsites are done, it'd be great if monthly de-briefs could happen where observed user behaviors, hangups, complaints, or compliments, could be shared/discussed from training and on-site support visits, and collected for consideration in future product development things. I adore @eloquence's OMGMEETINGSCREEP radar, though would like to nominate such a regular thing to begin happening? Too much lost value, to not do this. 😃

</uxkidDiatribe>

[emkll]

Outside of testing/dev scenarios, disabling buttons us an interesting idea idea, but we should keep in mind that disabling JavaScript is an effective mitigation for certain browser-based exploits [0] , as well as some potential fingerprinting techniques [1,2] .

Given the restrictive Content Security Policy on the source interface and assuming the source only visits the SecureDrop source interface, the server would need to be compromised and an malicious JavaScript file containing a sandbox escape would need to be served. I am guessing that it is also likely that a source has visited other sites with Tor Browser, and disabling JS may present some benefits outside of the Source Interface / SecureDrop context.

We should also keep in mind that #92 may very well require JavaScript to function, potentially providing opportunistic encryption of the submission client-side.

[0] : https://arstechnica.com/information-technology/2016/11/firefox-0day-used-against-tor-users-almost-identical-to-one-fbi-used-in-2013/ [1] : https://wiki.mozilla.org/Fingerprinting [2] : https://www.chromium.org/Home/chromium-security/client-identification-mechanisms

[ninavizz]

@emkll Hmm. Ok, so longer-term it seems we're kind of in a chicken/egg situation with Javascript, then, assuming it's desired to keep the road open in the future for the E2E encryption?

For now, an interstitial screen on the Submit page (done as a faux overlay)* has been one option that's been floated. It would NOT require a user to turn off Javascript, but it would whack them over the head quite a bit harder than the purple banner does.

The second option, would be a pre-entry interstitial (so, a "Welcome" page before the Index page) that would mandate the user turn off Javascript, to continue.

Between the two, do you have a preference? Disabling buttons almost always confuses users, even if/when they figure-out what is being asked of them. The psychological knock of coming-up against a wall and then needing to find your way out is also not good when a longer-term goal is education and training more pro-active security-centric behavior.

Finally—I'd love your thoughts around the urgency of this screen. All of the text on both screens I've shared here, are in "first draft" mode (meaning they reflect my own style of writing and my own thinking at 2am, more than a resolved team direction or what's hoped for a SD brand voice).

In discussing this screen, the point was raised that advising a user to simply quit and reboot may be easier, and could accomplish the same security protections. Thoughts?

* Ignore tone/voice of verbiage, as this is a first draft. It is likely far too whimsical, because that's just how my brain works—and these screens are still in the ideation phase.