Persist Tor Browser security settings warning across Source user flow

[huertanix]

Description

Currently, the purple ribbon warning used to advise potential sources to change their security settings in Tor Browser only appears on the first page of the Source interface. Once a user moves further into the Source user flow, even if they haven't adjusted their security settings, that warning disappears.

If "warning at the top of the page" is the design pattern we want to stick to, it should persist everywhere in the Source user flow as long as the user hasn't adjusted their security settings.

User Research Evidence

At the moment, the current warning doesn't get much attention from users (See: #2342). The lack of attention to the warning is a known observed user behavior among journalists asked to role play as sources. This doesn't solve that problem but adds some consistency to when the warning is displayed.

User Stories

As a news org, I want to make sure potential sources know how to increase their safety using SecureDrop and Tor Browser even if they happen to miss the first sight of the purple ribbon warning.

[ninavizz]

I agree with persisting the purple bar across the WHOLE experience, if a user is not using Tor. I actually did not realize that was not the behavior, today. This sounds like an important behavior to look at in future usability studies with Source users... however in the interim, I also want to squeak my wheel as loudly as possible to get that bar persisting across the whole Source Experience when outside of Tor, ASAP.

[huertanix]

To clarify when this purple bar shows up: The source interface afaik is only accessible via Tor due to being an .onion service, so the user is always using Tor, but the warning specifically appears when they're in Tor but have their Tor Browser security settings set to the standard level, which allows JavaScript, among other things. My understanding of how the warning appears (plz fact check me devs) is that it checks if JS is enabled and shows the warning if it is, and doesn't if it's not. It does only appear on the first page of the .onion side of the source user flow though.

[ninavizz]

^ You're totally correct, I mis-spoke in my comment.

Also, because Tor recently deployed their FABULOUS redesign of the tor button, I'd also like to get that new/updated icon in that bar, too. Of course, quick mockup forthcoming.

[zenmonkeykstop]

I know it's not exactly in scope, but based on a recent training, it might be worth seeing if there's a good way to display this message more prominently. In the words of a new user: "GDPR has trained me to ignore messages at the top and bottom of webpages."

[ninavizz]

Ohai! Would love to know what y'all think, of this E2E experience. https://invis.io/SBRK5N9G7RP#/357981326_Index_Immediate_TorWeak

Really curious what you guys think of the above. Yeah, the whole thing (banners, footers, messaging, show/hide Submit div) is totally not in scope, but iteratively working towards this stuff I also feel should be a priority.

@zenmonkeykstop the omnipresence of advertising for years, has trained users to ignore static things that appear in predictable places. It has to be thoughtfully woven into an experience (says while miming interpretive dance). Or, you need to include a picture of a brightly smiling young/thin/white blonde woman. Or pr0n. Why both are both so over-used, in ads.

[ninavizz]

Follow-up questions...

1. Is there an interest in getting just the purple-bar's contents updated this next sprint (or the following sprint)? I feel it would greatly improve the usability to add the tor button's icon into the purple bar, and to include its brevity/action-oriented text edits. @eloquence @redshiftzero ??

2. I would like to look into the broader issue of security stewardship with our Source users and Tor browser settings, in this next upcoming UX meeting. Along with other Source UX stuff.

@emkll @huertanix would you both be able to attend this upcoming Thursday AM at 9PST? Top curiosity I have, is to establish among ourselves the actual risk Sources subject themselves to, if they do NOT set that security slider to safest. I want to be careful to not be hyperbolic in the UX with warnings; if everything is a priority, then nothing is a priority, as the saying goes.

I do have one option sketched-out here for persisting the Security Settings stuff through the Source experience. A second option, would be creating an interstitial BEFORE the index page, that would require setting the security slider before entering the SD experience. Would any of these be overkill, or an accurate reflection of risk protection? Do we want to set that bar of mandating perfect security compliance for Sources?

[ninavizz]

...also, I don't know how critical it is for users to perform the "New Identity" action, at the end of their workflow. The messaging on the LogOut screen also needs to be updated, per updated Tor Browser UX (and imho, to more actionably influence user behavior).

The green onion icon in today's Tor browser is for the URL bar, and cannot do the "New Identity" schtick. It only shows Tor Circuit stuff. Separately, I don't like asking the user to perform 2 actions from this screen; the purple bar's request is basically obsolete at this point, and it should not be shown, here, imho. @emkll @huertanix ??

[huertanix]

@ninavizz I'll be at the UX sync meeting, would love to discuss these issues.

On the specific risk around the Tor Browser security settings, my understanding is that this addresses the possibility of any yet-discovered Firefox exploit which require JS to be turned on, e.g. https://arstechnica.com/information-technology/2016/11/firefox-0day-used-against-tor-users-almost-identical-to-one-fbi-used-in-2013/. Devs: pls fact check me if I'm misunderstanding the risk here.

[ninavizz]

Sidenote @huertanix: There's a slight chance I won't be able to make it this week, if a funding call needs to happen. TBD.

[ninavizz]

Concerns around this are on the docket to discuss at the UX meeting on 25 Apr: https://github.com/freedomofpress/securedrop-ux/wiki/UX-meeting-20190418