Improve UX for sources

[heartsucker]

I have noticed a few problems with sources sending us things.

1. Sources don't "get" SecureDrop

It is rather obvious that many of the source who send us docs or messages have not read the the docs provided by FPF and do not fully understand the security ramifications of their actions. This includes linking to documents hosted on their (presumably) personal Gmail/Dropbox/etc. accounts. I think the expectation that sources will read any docs prior to submitting is unreasonable. GlobalLeaks does a little bit to inform the user during their leaking workflow.

A possible solution would be to include a warning page that a use has to click through before leaking their first doc that explains some Do's and Don't's.

2. Sources don't understand the importance of their user name

We get a number of leaks under different user names that are clearly from the same person. This could be N documents in a series, or the person referencing things in a separate conversion that the would only know if they had access to that account.

There was a recent change to hide the username behind a disappearing CSS div which I think is the opposite of what should have been done. A user should have to type and submit their username into a box and submit before they can leak, thus confirming that they understand what it is.

[psivesely]

How about redirecting from /generate to /? When they click "continue" it will save the codename in the db, but they'll still have to manually type it in with no on-screen visual aids before they're able to submit their first messages.

[redshiftzero]

Thanks for these points @heartsucker!

First, great points in 1. At this point we’re expecting sources to read the organization’s landing page and FPF’s docs, but much of this advice would be most effective if these security pointers were in the app itself. Some of the advice however, will need to remain on the organization’s landing page, for example any advice about how to safely get TBB. A few things could be done to improve the source workflow here:

1. Point sources back to the landing page to let them know there is really important security advice there. This could be done by adding the URL of the landing page to prod_specific.yml and then linking back to it in the warning page to be created.
2. Add the security advice relevant to the step when a source is already at the Onion service to the new warning page (e.g. don’t link to personal Dropbox, documents have metadata (also see #119, #122, #543)). The issue here is that this advice may differ based on the organization. So ideally we’d include some reasonable default text and then give organizations the option to customize it.

Also on the source UX side, there is an older issue (#479) also worth implementing regarding providing a source with additional information about the next steps after they submit.

On point 2, I also see where you are coming from. I think it’s good that the codename is not displayed on screen by default after its initial generation. I also imagine that there will always be sources appearing with multiple codenames because they have 1) lost their codename or 2) elect to get a new codename each time they visit the organization’s SecureDrop (perhaps because they do not have a secure place to store a codename and they have a poor memory). However, I agree that we should make more clear that the codename is important and not simply something to click through and ignore. Adding a “Type your codename and click submit” would be a nice improvement here!

[psivesely]

A possible solution would be to include a warning page that a use has to click through before leaking their first doc that explains some Do's and Don't's.

I think this might be good for the first time they log in. Just a single page with not too much text. Care to propose some text @heartsucker or anyone? I don't think we should be instructing sources to use MAT honestly--not that that's what you were suggesting @redshiftzero--but it is good to remind them their documents have metadata. What would be cool is to automatically run MAT on all submissions on the application server before encrypting to the SVS key.

[redshiftzero]

One note: we probably don't want to autorun MAT because the metadata is useful by journalists for verifying source documents.

[psivesely]

https://github.com/freedomofpress/securedrop/issues/497 Was once there removed for seemingly sound reasons. I think Garrett makes a good point here https://github.com/freedomofpress/securedrop/issues/497#issuecomment-50846582.

[psivesely]

I take back my suggestion of auto-running MAT on the application server--it was just a quick idea, that I had not thought out. See the last few comments of https://github.com/freedomofpress/securedrop/issues/122 for more.

[heartsucker]

@redshiftzero @fowlslegs Can I claim this one for the hackathon this weekend? I know the tag was applied, but I think I can bang out a fix in a day or so. My plan would be to have a single informational page each source would have to confirm once before submitting, though I think this would require adding a column to the DB to persist it across sessions.

[redshiftzero]

Sure! We're planning to have people comment on Github on the issues they're interested in taking on for the hackathon to minimize duplicated effort, so consider this one yours.

[psivesely]

I agree the new DB column should be fine--won't expose any additional info should the database be compromised in the future.

[psivesely]

@heartsucker Also, what do you think about redirecting sources the homepage after codename generation, so they have to enter it in before submitting the first time? My concern with that is they will copy it to their system clipboard, which would be bad if they weren't running an amnesiac OS.

[heartsucker]

@fowlslegs Good point about the clipboard. I can add the following css to the code name on all the pages.

-webkit-touch-callout: none;
-webkit-user-select: none;
-khtml-user-select: none;
-moz-user-select: none;
-ms-user-select: none;
user-select: none;

I think this should work as long as we put a div/span around every occurrence of the code name.

I think this is a better approach than looping them back to / because this could be annoying or frustrating, and also is only indirectly stating the importance of the code name. Explicitly saying "this is your code name, now type it here to continue" would make it very obvious that it is important.

[heartsucker]

Also, in the event anyone else wants to poke their nose into this, my branch is here: https://github.com/heartsucker/securedrop/tree/source-ux

[psivesely]

@heartsucker Plan sounds on point :100:. Thanks for bringing this one up, and good idea on the CSS to avoid copying to the clipboard.

[ninavizz]

Hey folks! So: expecting users to read more than two sentences at any point in time, is (regrettably) not reasonable, per norms established in many cogsci & usability studies. Doesn't matter how truly important information is—human behavior has simply been proven to not work like that.

SecureDrop could be that parent screaming at their child to behave better in KMart, by DOING LOTS MORE ALL CAPS TEXT, requiring tons of check-boxes to say "yes, I've read that," and frequently berating users to read pages of documentation. But, just as the child screamed-at by mom in a shopping cart is more traumatized by the affects of such messaging and subsequently fails to retain (or frankly care about) corrective behavior opportunities, users function identically.

There's a reason airlines do the pre-flight safety videos, instead of handing passengers a multi-page pamphlet with a wide-eyed plea "YOU MUST READ THIS!"—and, why Virgin America has gone the extra length, to make their video playful. When users pay attention and are enjoying the intake of knowledge, they retain the information better. It's why us geeks are just better at this stuff, than our parents—we enjoy reading pedantic infosec stuff, and frankly seek it out when it's not shoved in our faces. The Medium Is The Message. <3

The best solution would be to produce a video with professional actors, outlining all of the critical points written about at length, in the user guide. Then, to provide a crib-sheet for folks to reference, afterwards. Communicate the urgency and rationale behind various points in the video, then use an accompanying PDF as bulleted "do/don't do" cheat-sheets. Yes, a PDF, because artwork/drawings are important.

I've been thinking about this for a few days, and asking the three former Mythbuster co-hosts (Kari, Grant, and Tory) to volunteer their services in helping SD produce such a video, I think would be a terrific idea. They've worked with writers at Mythbusters for years, to chunk-out complicated ideas and create accompanying animations, to explain tough-to-follow information to viewers. They're also all local to the Bay Area. Grant is well known in the local robotics community, and I suspect all three have a soft-spot for what FoTPF and SecureDrop are doing. They could be asked to help in one of two capacities: a) simply show-up for an afternoon to be the professional actors in the video, or b) work with a writer/storyboarder at FoTPF to ideate through text and drawing ideas, then act in the subsequent video.

Yes, professional actors do contribute hugely to such an effort, as vocal cadence, body gesturing, and on-camera appeal actually matter quite a bit, in how effectively info is communicated.

Alternately, Xeni Jardin and Mark Frauenfelder could produce such a video as a BoingBoing TV piece (or in the same fashion a BBTV piece is done), with guidance from FoTPF on what to instruct users on. It seems prescient to do such a piece, so why not?

I'm working on incorporating all these concerns, separately, in my UX stuff... but we can only do so much with chunking-up text, re-writing things, redundant "FYI" reminders where contextually relevant, and interaction tweaks. The core issue here is education and awareness of complex issues not many in the general public are familiar with. Video, baby.

[toholdaquill]

On Sat, Dec 24, 2016 at 02:48:35PM -0800, Nina Eleanor Alter wrote:

I'm working on incorporating all these concerns, separately, in my UX stuff... but we can only do so much with chunking-up text, re-writing things, redundant "FYI" reminders where contextually relevant, and interaction tweaks. The core issue here is education and awareness of complex issues not many in the general public are familiar with. Video, baby.

If you need a manual, much less a video, doesn't that suggest there is something wrong with the UX to begin with?

Doors with handles that say "PUSH" come to mind...

jmp

[heartsucker]

@toholdaquill Security is not simple, easy, or intuitive. Professionals mess up all the time, so I don't think it's just a UI thing. For example, if a source dumps something to a SD instance and doesn't clear their browser, they can be fingerprinted on other sites. This is entirely out of our control, and the best we can do right now is show some text and hope they read it.

[ninavizz]

SecureDrop does things much differently than DropBox, Yahoo!, and most of the other dominant experiences out there for filesharing and communications. It does so, because of necessitated security measures. Yes, the UX of each task flow does need to (and can!) be intuitive—but that won't impact user emotions or core user behaviors, such as why my parents won't understand the urgency behind why they can't just use SecureDrop on Tor from their household wifi, or with my mom, why she can't get her library to install Tor so she can use SecureDrop, there.

Security stuff is equal parts intuitive/usable UX within the application task-flows, and then advocacy education as a wholly separate thing, to set the stage for user confidence and both reasonably feeling and actually behaving safe in an environment totally different than the Amazons or Gmails that just want to coddle your ego and suckle your soul to sell you shit. Chips & dip: stale chips or sucky dip, negate the party tray... but when they both rock, ohyoyyoy! The general public needs to learn what "conveniences" come at which costs, what alternatives exist, and how to evaluate each, so they can plan accordingly. Without ever reading a manual. :)

Also: SD is an open-source/none-profit project. Sure, there COULD be things the team could do to make some parts of the app more usable (like catering to users who can only share things from DropBox or GDrive links via special fields to upload files from those places & then scrubbing the system of the submitted file-paths), but do they have the financial resources to dedicate to developing those features/feature-changes—and would those take priority over things that would make the system more desirable for media organizations to adopt or maintain, or for journalists to communicate with sources, or a more secure environment, in general?

So, for a product like SD, much of the user's total experience includes acquiring knowledge about basic security concepts like encryption, IP tracing, how 3rd party services open opportunities for malware, etc. But it can't be shoved in their faces mid-task-flow when using the application, nor scolded to them in YOUMUSTREADTHIS gobs of text held over their heads before entering the app. Hence my suggestion for videos, animations, or other multimedia means to educate in a fashion compatible with the 21st century brain, as an ideal solution. Much more immediate term: hoping to chunk it all up into more readable/ingestible user guides w/ nice/clean illustrations, for sources.

Yes, from one of the most longwinded chicks on the planet (me!).

[psivesely]

Somehow I missed the last 4 comments...

The best solution would be to produce a video with professional actors, outlining all of the critical points written about at length, in the user guide. Then, to provide a crib-sheet for folks to reference, afterwards. Communicate the urgency and rationale behind various points in the video, then use an accompanying PDF as bulleted "do/don't do" cheat-sheets. Yes, a PDF, because artwork/drawings are important.

If we instruct sources to turn the Tor Browser Bundle (TBB) Security Slider to "High" (see https://github.com/freedomofpress/securedrop/issues/1024 and https://github.com/freedomofpress/securedrop/pull/1480 for context), this makes videos click-to-play, which doesn't look so hot:

We think it's quite important that sources do this, so while a great idea, perhaps we'll have to settle for a fun graphic with the most important information we can give to sources in two sentences.

This is not even to mention how slow downloading a video from an onion service, which means passing through 7 intermediary Tor nodes (8 if you're using a bridge or transport), can be.

This is just as far as the SD application goes. I think the video is actually still a very good idea to include on the securedrop.org website.

I've been thinking about this for a few days, and asking the three former Mythbuster co-hosts (Kari, Grant, and Tory) to volunteer their services in helping SD produce such a video, I think would be a terrific idea. They've worked with writers at Mythbusters for years, to chunk-out complicated ideas and create accompanying animations, to explain tough-to-follow information to viewers. They're also all local to the Bay Area. Grant is well known in the local robotics community, and I suspect all three have a soft-spot for what FoTPF and SecureDrop are doing. They could be asked to help in one of two capacities: a) simply show-up for an afternoon to be the professional actors in the video, or b) work with a writer/storyboarder at FoTPF to ideate through text and drawing ideas, then act in the subsequent video.

That would be hella cool!

So, for a product like SD, much of the user's total experience includes acquiring knowledge about basic security concepts like encryption, IP tracing, how 3rd party services open opportunities for malware, etc. But it can't be shoved in their faces mid-task-flow when using the application, nor scolded to them in YOUMUSTREADTHIS gobs of text held over their heads before entering the app. Hence my suggestion for videos, animations, or other multimedia means to educate in a fashion compatible with the 21st century brain, as an ideal solution. Much more immediate term: hoping to chunk it all up into more readable/ingestible user guides w/ nice/clean illustrations, for sources.

It seems reasonable, that for the securedrop.org website, anything goes, but for the SD application, we'll have to limit such material to certain formats. We should still strive to make information in the SD app as accessible as possible, but might be limited to fun graphic images as a means to do that.

Thanks for all the feeback @ninavizz.

[ageis]

Heh, it occurred to me the other day that with a little JavaScript👎 then you could easily have a button which copies the source codename to the clipboard, and that it might be a UX win. Is clipboard really truly evil? I don't know. In an unlocked and powered-on state, yeah. And it's bad for data to escape the isolation of the browser and become available to other programs.

As a related tangent, which maybe doesn't belong here, everyone's known forever that the super-privileged X.Org Server suffers from an insecure design, as any process with access to the DISPLAY can snoop on any other. Wayland is superior and has some awesome security modules which would be incredibly useful to paranoid people. Check it out—you can set a policy controlling access to clipboard, screenshots, pointer, keyboard, focus etc. It's a real shame Tails 3.0 is still running X and this isn't being looked at more.

[ninavizz]

Could this issue perhaps get closed, archived, or sumptin'? At a minimum, the "Pending PR" label should get removed. 😃

[eloquence]

Yes, this can be reasonably closed at this point. Good discussion, but we can revisit some of these questions in the context of continued iterative improvements to the source experience.