Securedrop: Rethink Javascript warning, part two

[micahflee]

Long ago I opened issue #1024 about replacing the red warning bar that suggests that sources disable Javascript with one suggests they set the Tor Browser security slider to High instead. Some progress has been made (#1480), but the more I think about it, the more I wonder if the warning just shouldn't be there at all -- or rather, replaced with something else.

It's no question that setting the security slider to High reduces the browser attack surface. But this is just one small piece of advice out of a myriad of other advice we could give, and I don't think it's even the most important. A much more important piece of advice, for example, is "don't tell anyone that you're a source." Or we could tell sources to use Tails or Whonix. Or we could tell them not to use SD from work, and to always use it on a personal computer.

In this context, the scary red warning bar that's specifically about Javascript seems a bit arbitrary.

Also, I'm not convinced it's always sound advice -- there are downsides to setting the slider to High, like it makes many websites completely break, which might be confusing and challenging for people. I obviously don't have data on this, but I suspect that most SecureDrop sources use Tor Browser for submitting to SD, and that's it. When this is the case, the only actor in a position to hack the source using a JS-based Tor Browser exploit is the journalist org that's running the SD server, or someone who hacks that server, and that's it. (Disabling JS is more useful for people who use Tor Browser for email services like SIGAINT that they actively use, or are regulars on forums or markets, or run a twitter account.)

Maybe the red warning bar should be completely removed, and instead that can just be a link in the footer to https://docs.securedrop.org/en/latest/source.html (or maybe a new documentation page, or maybe one hosted within the SD website to avoid referrer headers) where it describes various tips and tricks for staying secure as a source.

[garrettr]

When this is the case, the only actor in a position to hack the source using a JS-based Tor Browser exploit is the journalist org that's running the SD server, or someone who hacks that server, and that's it.

This is exactly the concern that the "disable JS" warning is meant to address, inspired by the technique of deploying NITs (network investigating tools) to deanonymize Tor users (e.g. Freedom Hosting).

[micahflee]

Yup, it's definitely good advice. Also, always keeping Tor Browser up-to-date will likely defend against this as well. I just mean, I'm not sure that this should be a red security warning, so much as part of a list of security advice that sources might want to follow.

[psivesely]

A much more important piece of advice, for example, is "don't tell anyone that you're a source."

I think that's too implicit and would make for a weird flashed banner image.

Or we could tell sources to use Tails or Whonix. Or we could tell them not to use SD from work, and to always use it on a personal computer.

I don't think we should be flashing messages geared towards advanced users on the homepage.

Agree with what @garrettr said.

I'm not sure that this should be a red security warning

We're redoing the design at @ninavizz's suggestion to something a little less scary/punitive. See https://linx.li/fx82grcw.pdf

[ninavizz]

Red = OMGWTF!!!

I'm working with the Tor folks to get that damn slider more discoverable, on an aside—but their devs are much less amenable to working with UX than y'all are. That control is also apparently quite hard for them to work on, but I'm chatting with their usability person next week to see if we can come up with something better for the dev team to implement.

Usability matters, and it sucks that so many in the security community are so hostile to ideas from folks, just cuz we don't f*ing code. Users pay the price, and SD/Tor users can't afford that price. If anyone here knows folks in dev leadership at Tor, I'm sure Lucy could use extra voices piping-up on the urgency of making that slider either a toolbar-accessed interaction, or clearly visible as "Tor Slider" in a dropdown. I empathize that it's a tough implementation likely to need repeating w/ every new Firefox release, but losing your career, being arrested or getting disappeared, I'd imagine to be much harder.

[micahflee]

@fowlslegs changing the red warning bar to purple does improve things a lot. It reminds me more of those "this website uses cookies" notices, less of "WE'VE DETECTED AN ATTACK" warning. Ideally, there should _only_ be warnings when there's actual danger, but at the moment there's a warning for every single user, and nearly all of the time (most likely 100% of the time, so far) there has been no danger.

I agree that there shouldn't be flashing messages geared only to advanced users, which is why I suggested adding a link to the footer instead. I also agree that it's awkward to flash a message saying "don't tell anyone that you're a source" though it's far from implicit- talking to someone about being a source, nothing at all to do with technology, is how Chelsea Manning ended up getting arrested. My point was just that, in terms of requesting that the user jump through hoops, this is just one of many hoops that could be presented, and while important, not even the most important one.

What would be awesome is if websites could set an HTTP response header that Tor Browser watches for, something like X-Tor-High-Security: 1. If that's set, Tor Browser would treat the tab as if the security slider were set to High, no matter what the security slider actually is. This would fix the problem directly in the client, without needing to scare the user or make them jump through any hoops that they shouldn't have to even think about. I'm sure SecureDrop sites aren't the only sites that could benefit from a Tor Browser feature like that.

[micahflee]

Just opened an upstream Tor Browser issue to see if they're interested in the X-Tor-High-Security header idea: https://trac.torproject.org/projects/tor/ticket/21418

[psivesely]

I agree that there shouldn't be flashing messages geared only to advanced users, which is why I suggested adding a link to the footer instead.

Not a bad idea. You should take a look at the 0.4 and 1.0 (don't know for sure if these will be the actual releases the changes will land in) wireframes @ninavizz made. She already made some suggestions as to where to put and how to introduce "advanced user messaging."

What would be awesome is if websites could set an HTTP response header that Tor Browser watches for, something like X-Tor-High-Security: 1. If that's set, Tor Browser would treat the tab as if the security slider were set to High, no matter what the security slider actually is.

The problem with that solution is if the site gets compromised, the server might decide to stop sending that header. Of course you could monitor such a thing. With the current method, assuming a source only uses TBB for SD, they basically have to TOFU the Security Slider warning will be there, and then after that, it doesn't matter if the site is compromised and stops showing the Security Slider warning. The Security Slider setting can be persistent because it gives basically no information to someone who gains access to the machine, whereas, for the same reason TB can't save HSTS headers, it couldn't save "Tor High Security" headers.

[ninavizz]

I LOVE Micah's idea, and would like to include it as a 0.4 feature. Some monitoring does need to get built-into SD to relieve users of so many of the existing things we burden them with. I realize security mandates a lot of manual stuff by-nature, but the request for users to change their browser settings AND to double-check the .onion address on the landing page, are just too much. I'd really prefer it if in 0.4 monitoring of both pages, could be done, to aleveate those two yooge things offa the users.

As it is, we're removing the Source user's expected opportunities to receive notifications and have login name recovery available. I think users will be fine with those two, but we need to step-up to meet them halfway by making the other two done by the system.

[psivesely]

double-check the .onion address on the landing page

I'm not sure what user requirement you're referring to.

I'd really prefer it if in 0.4 monitoring of both pages, could be done, to aleveate those two yooge things offa the users.

This can only happen if Tor implements and ships this change by 0.4 (very unlikely).

As it is, we're removing the Source user's expected opportunities to receive notifications and have login name recovery available. I think users will be fine with those two, but we need to step-up to meet them halfway by making the other two done by the system.

Still not sure what you mean by the other one (re: my first reponse). Even if Tor implements, merges, and ships the feature Micah describes. We still have to build monitoring infrastructure (not too hard to just check that each server is sending the correct headers), buuuut not all instances will/ should have to sign up with us. It would be nice and I believe safe for the monitor server to curl the app server at random intervals, do some checks, and potentially send some alerts. curl is fine because we'd only be parsing the HTML body (or potentially only the headers). Not that rendering HTML is super dangerous, but moreso than just parsing.

[ninavizz]

@fowlslegs On the Directory page of the SD website, at the top of the table it warns users to please always double-check the .onion address newsroom landing pages show, against what's on the SD Directory page—and that if there are discrepancies, to not proceed but to instead contact SD immediately, through crypto-Email. All of that, is too much. SD "lectures" users too much. Most infosec software does that, too—and it's a bad practice. Users _do_ need to be educated, but not when the user has established a need to accomplish a task... and they're getting lectured while also trying to do that new thing for the first time. It's like being taught the social rules of driving while you're behind the wheel on a public road for the first time ever, versus first some stuff in a classroom—then, go drive—then more classroom—etc.

The newsrooms should be asked to create fully-independent landing pages for SD stuff; so, for the NYT and other orgs who have a looong page w/ many secure contact options, create one additional https page w/ HTML/CSS the SD team will send them (or they can create from a to-be-built handy-dandy admin page). The "official SecureDrop Landing Page" should then be monitored by FOP, and if any changes are made, ever (as none should ever be, unless the .onion addy changes), a human at FOP will be notified to check it out—and until then, the LP gets re-directed to a "Our SecureDrop is down, right now—please come back in 48hrs" page (which either the monitoring system could automate, or a FOP human would have to do).

It's ok that SD asks users to use Tor, and to turn-off Javascript, and to find a cafe to work from. It's also understood imho, that SD cannot send notifications to let Sources know a Journalist has responded to them. The value for all of the above, I'm hypothesizing to feel clear enough to most users. We need to "pick our battles" though, with what we ask users to do—and it's just too much, to ask them to do much more than that (to double-check the .onion addresses, to not share links to docs in the cloud, to memorize their passphrase vs writing it down—and to lecture in that ask, etc). Then on top of it, should there be a mismatch, they're being asked to use email clients _and_ a process/protocol known to be unusable to non-technical folks. It's silly, to be honest, but ultimately it puts the users at risk, because they simply won't do those things—and beyond not doing them, we've lectured them and made them nervous, beyond missing the opportunities to educate them in a cognitively sustainable fashion.

I appreciate (intensely!) that FOP's resources are thin, but we should still get those project(s) together and "Help Wanted!" tag them—and should they sit for too-long unattended to by volunteers, then have a hackathon or present the need in a blog post and Tweets, to help get 'em built.

[psivesely]

Closing this because we have modified the JS warning and made the SI Security Slider High compatible. If they ever implement your ticket Micah, feel free to re-open and we can discuss then. I think tom's comment in that thread is not really a worry because we'd have the same problem if it's compromised now. It seems only monitoring can ameliorate the issue.

[psivesely]

Or the X-Tor-High-Security: 1 preload list, which requires getting your feature implemented, and then getting support for that implemented, and then maintaining such a list.