Compose content for "Source Safety Guide"

[ninavizz]

Description

Content needs to be developed for this page, currently nicknamed the Source Safety Guide. Until content has been created, edited, and approved, this page cannot go into the SI. This is the prototype demonstrating the page in action.

More than 3 sentences together in a "chunk" is ill-advised. The above implies a progressive/disclosure pattern, likely using the <summary> and <preview> tags in HTML. The contents of this entire page w/o expanding sections, should be consumable in less than 5 minutes. It is intended to be a very short read, or the "TL;DR" version of what we all wish they'd read.

Current SI design principles:

1. Design for users Whistleblowers are a wide and varied group of humans. As a childless, young engineer, Ed is an anomaly among whistleblowers. Look to our Source Personas and Who Are Whistleblowers, to evaluate considerations against.

2. Guide behavior to inform safe choices Behavior. What the user cognitively consumes, and connects to behavioral actions. Knowledge-informing text is for articles, not in-app text. Martin should be an especially good person to guide this, having done user research.

3. Seek to contain chaos/confusion in all visual or written language choices. Reduce cognitive friction, cultivate calm. Written language(s), visual language, the complete experience journey.

4. Clear, human, humble, neutral Aesthetics should be visually appealing and easy to consume, without calling attention to the artifacts themselves. SD is the messenger, not the message.

5. ACAB "Policing" approaches to opsec guidance come from the best of intentions, yet carry as many not-obvious drawbacks as policing in civil society does. Unfortunately, wishy-wash wrapped in too many words, is often employed as its alternative. There is a middle ground—and we need to strive towards finding that. It is hard, but The Force is strong with this one!

User Research Materials

Source Personae (created for 2018 SecureDrop Retreat in NYC; aah, the carefree days of business travel!)

Who Are Whistleblowers Exercise created for User Feel users; mouse over historic whistleblowers to learn their stories.

Evidence from user testing or actual users, no. Assumptions based on general knowledge of vulnerable and non-technical users, yes; as well as a general understanding of user behavior—that most people will never read even a percentage of what we'd like them to. Their life often depending on their consumption of that content, is logic we mis-attribute to known realities of human behavior.

User Stories

I am a person with highly sensitive information about my employer, that I would like to share with New York World. I am not an activist or a tech-person at all. I am a mid-age career middle manager or an executive with a private industry producer of energy, pharma, agribiz, or financial products, or a public sector entity. I have no idea what a "threat model" is, and have kids and a busy life at home that prohibits my spending hours learning about new-to-me technology concepts.

I have spent several months considering an ethical dilemma at work that the information I'd like to share, provides evidence about. If my employer finds out I leaked this information, my career may be over; mine or my family's personal safety could be at risk; I could lose my professional licenses, or I could go to jail.

SecureDrop has come to my attention as the safest way for me to anonymously share information.

Within the context of using SecureDrop, I'd like some basic and high-level areas of risk to be brought to my attention, that could lead me to accidentally having my activities revealed to my employer, or my anonymity blown. Things I may not have encountered on the New York World's website, or otherwise would not have thought to look for. I'm a boring adult, and the passwords my kids are now forcing me to use because they're supposed to be safe, already overwhelm me.

Mic drop from Nina, as at least one person shakes their head and giggles at the 3-paragraph user story with built-in persona

[ninavizz]

This is the page* that had previously been worked on, collaboratively, for this content. Upon reviewing it after letting it sit for several months, it was my own judgement that this is faaar too much content for within the SD experience, itself—hence, paring it down, significantly, in the Paglen-enhanced overlay, above.

* If you need permissions to edit or access the Figma, let me know!

[ninavizz]

Also of note: the image used in the overlay right now, is an image of Trevor Paglan in a gallery exhibit for one of his own works (the giant silver cam-ball). Paglan himself would need to be contacted, and able to provide the name of the photographer and gallery—with both consenting to use of this image. Yes, I will personally volunteer to do that, off the clock, to facilitate use of this image. I may need some help from FPF Trevor, tho, to at least make the initial contact to the-cool Trevor.

[ninavizz]

NOTE: This approach killed, ignore this comment... FYI, would be nice if there could be a point to speak to this. Users in testing also commented that they wanted to see a history of what they'd submitted to news orgs—and that feels like a relevant by-design thing to also speak to.

[ninavizz]

Poking @huertanix @martinshelton @harlo! We're about to begin scoping the updated design for implementation. For this to get built, the content needs to be confirmed to be complete, first. I'd love to see this happen, so just offering a nudge, here. :)

[huertanix]

@ninavizz Just to double-check my assumptions on the state of this copy: 1) It exists but it's long/unwieldily. 2) Copy can be adapted to the outline structure you posted a screenshot of, but still needs to be written/re-written?

[ninavizz]

@huertanix Yep! Formatting should follow what is shown in the Figma; so...

1. FYI, per pre-break discussion with Kev, final page may or may not be an overlay, tbd
2. Page description (below H1) should be no longer than 2-3 sentences.
3. Concept "summaries" should be concise, and tensed as shown
4. Descriptive text before the "Continue Reading" linx should be no more than a Tweet's worth of text before.
5. Text exposed when the user clicks "Continue Reading" should be no more than 2x the text before. If needed, should link-out to other .onion pages.

Open to Question:

1. What are the most important concepts to show, here (eg: printer dots, shoulder surfing, clearnet vs Tor)?
2. In what order should these concepts be shown?
3. Wordsmithing, actual text; but following consumability/usability parameters above.