Securedrop: HTTP only onion services produce warning in current TB

[redshiftzero]

Firefox added a warning to indicate when a user is interacting with a username or password input field on a page served over HTTP. In the current release of Tor Browser, 7.0.1, this is enabled.

Unfortunately, this means that currently on the source interface (for the SecureDrop instances that don't use HTTPS on the source interface), a warning appears:

Similarly on the journalist interface:

This warning is intrusive (by design) and may scare away sources from submitting. The best solution here is to start using HTTPS for both the source and journalist interfaces (relevant: #1605 for the source interface). If there's another viable solution here (i.e. one that does not train users to click through security warnings), feel free to comment.

[psivesely]

I'm going to file a bug upstream to see if Tor will remove this feature for .onion sites.

[psivesely]

Already being tracked in https://trac.torproject.org/projects/tor/ticket/21321 .

[psivesely]

Looks like the Tor Trac ticket was given priority for resolution and labeled for July. Maybe we'll see it in one of the upcoming 7.0.X point releases in the next couple of months?

[garrettr]

Looks like a PR was posted in the upstream issue earlier today; fingers crossed that this will be fixed in an upstream release of Tor Browser soon!

[garrettr]

I just discussed this issue with @redshiftzero. We agreed that it is challenging to address for a number of reasons.

We do not have a mechanism for receiving feedback from the anonymous sources who use SecureDrop, so it is difficult to gauge the potential impact of these warnings on end users; however, from our own recent encounters with the warnings from doing QA for SecureDrop 0.4, as well as reports from journalists who use SecureDrop, we have reason to believe these warnings are creating confusion and uncertainty for end users.

Since these warnings were introduced upstream in Tor Browser, we cannot directly resolve this issue. The currently available mitigation strategies are:

1. Wait for the issue to be resolved upstream.
2. Encourage more SecureDrops to deploy HTTPS. The first-class support for HTTPS on the Source Interface in SecureDrop 0.4 helps mitigate this issue on the Source Interface (but will not mitigate it on the Journalist Interface).
3. Add an "anti-warning" to the affected login pages, e.g. "While you may see a warning saying that logins entered here could be compromised, you do not have to worry because... etc.".
   
   
   
   • @redshiftzero and I agreed that training end users to ignore security warnings is an anti-pattern, and we should refrain from adding such an "anti-warning" to any of the SecureDrop web application pages.
   
   
4. Add a note to the documentation explaining the issue.

We agreed that it may be worthwhile to implement 4 while waiting for 1.

[mrphs]

This issue has been resolved. See https://trac.torproject.org/projects/tor/ticket/21321

[garrettr]

Thanks for the heads-up, @mrphs! I've confirmed this issue is fixed for SecureDrop in Tor Browser 7.0.5.

Hopefully TB 7.0.5 will be included in the next stable version of Tails, which will fix this issue for all categories of SecureDrop end users.

[redshiftzero]

Tor Browser 7.0.4 fixed this issue, which was included in the latest version of Tails (Tails 3.1), so closing.