Disable Source Interface on instances running Trusty after April 30 #4305
Comments
|
Pinging self to get on my radar... likely just messaging (or, time for a "sailed-ship" icon, heh)? |
|
Follow up from the discussion during sprint planning, this is a minimal implementation that would achieve this functionality. # file `disable.py`
DISABLE_DATE = date(2019, 4, 30)
def disable_app(app):
@app.before_request
def disable_ui():
if date.now() > DISABLE_DATE:
return send_file('path/to/static/file')Then we we add the following lines to import disable
def create_app(config):
# snip
# this must occur in before any other `before_request` decoration or extensions
disable.disable_app(app)
# snipThis works because if a |
|
Thanks @heartsucker that solution looks good for the near term. I agree that the flask method is the most prudent in the near-term, but we must also be prepared to disable the source interface at either Apache or THS level if there's a remotely exploitable Tor, Apache, Python or Flask vulnerability in the future. Perhaps worth tracking in a follow-up ticket once a PR is opened. |
|
WIP branch here: https://github.com/freedomofpress/securedrop/tree/4305-disable-submissions-trusty-eol The current UX is very simple, and is identical to the current Source Interface generic error page: |
|
I'd assumed we were seeking to block both from submitting and Messaging. I'd prefer to be clearer with users, and had composed the below—based off the current Index page (tho I moved the languages widget to below the logo, because I'd prefer that gets moved on the Index pages anyway):
|
|
Related general nit: Preference to avoid use of nrrdspeak like "instance" and "mode" in user-facing content, on the Source UI. Yes, most folks can figure those things out, but they impose an emotional burden onto users I'd like to be sensitive to avoid. Sources are already taking quite a leap by engaging with a SecureDrop at all. <3 |
|
Thanks @ninavizz , great points. Yes, submissions and replies will be disabled. I've updated the wording based on your feedback, what do you think?: The rationale is that I would prefer if we kept the messaging generic as possible: since sources are likely to originate from the org's landing page, they can elect themselves to submit documents through other means (if they choose and if available). Does this make sense? |
|
@emkll It makes sense, but I still am not comfortable with the terseness of that. It’s very important to point users towards a path for probable success, when effectively slamming a door in their face (which this kinda is). |
|
@ninavizz, thanks for your helpful user-centric input here. We have to be careful communicating on another organization's behalf, even if that does make the message a bit more technical or opaque. It is ultimately the news organization's job to clarify the status of their SecureDrop on their landing page, and we cannot make judgments about this on their behalf or offer too much in the way of resolution. Even a statement like "We don't know when our SecureDrop will be back online" IMO presupposes too much about the other organization. We should not speak on their behalf in this manner. Similarly, we cannot say with certainty that other contact methods are available on the landing page, or that the organization is currently prepared to process submissions by other means. I would therefore suggest sticking with simple language, e.g.:
(Note the avoidance of "our".) |
|
@eloquence I hear yous and @emkll's concerns.
Feeds into a common mental model other online services have established in most users, that later the same day, or in a few days, might work. We however, know that is unlikely to work.
Again, working with user mental models here; that makes this look like a phishing page, or like they're on the wrong page. Especially for orgs that don't use a custom logo and instead use the SecureDrop logo. Why would any org not speak to its users in the first-person? It's a standard expectation; and with commercial integrations, 3rd parties do it all the time in their generic/default copy. It's not possible with any software solution, to 100% appease the needs of the customer, the end user, and larger behavioral interests. So tradeoffs have to be made. Are we out to protect the users first, or to represent all organizations as neutrally as absolutely possible, first?
IMHO is appropriately vague for messaging users. Bottom line: we've given orgs over a month to update their systems. If they're neither communicating with FPF nor with their own users, why are we sticking our necks out for them at the expense of user expectations management, in this messaging? I feel it's entirely fair if an org gets up in a huff, to say just that: we gave y'all a chance, we went out of our way, and we needed to shift our prioritization to the users. If an org has in fact not yet upgraded to Xenial by now, what is the likelihood that they ever will—if they've also ignored all our outreach? That is also a very real thing to consider, that I want to respect Source expectations around. |
|
Regardless of news orgs ignoring the need to upgrade, I don't think it's appropriate for FPF to "step in" and communicate on their behalf as "We" on the source interface index page, even in vague terms like "We don't know when our SecureDrop will be live again", or in terms of giving specific recommendations to sources. But I also need to reiterate that this is quite time-sensitive, so one way or another we should finalize the wording ASAP. @redshiftzero could you act as a tie-breaker on this wording question? |
|
I would be ok with killing the "We" to get more neutral with Who owns the servers, and SecureDrop not being this global monolith thing, is a very important concept to communicate to Sources. This is the Customer's SecureDrop. We're irresponsible to not speak directly to that. |
|
I'd suggest the following compromise language:
I still think "try again later" is fine; it could indeed be days (this change may motivate organizations to upgrade). Beyond that I don't think we should make statements on the org's behalf. I'm OK with "our" for statements that are unproblematic and unlikely to contradict the news org's other public comms. But consider:
In those cases we should not contradict what the org is saying by making presumptions on their behalf like "We don't know when" or "consider X". In future, if the source interface becomes more customizable, we may be able to offer richer templates, but given that there's no org preview or sign-off involved in rolling out this change, nor any customizability, I would argue for conservatism whenever we speak as the news organization to the user. That said, I'm fine with whatever final language Jen signs off on. |
|
Ok—fair point on the "other means to communicate with us..." bit. Only remaining nit then, is structural—and a general UI copywriting best-practices nit I have across SD documentation, Source UI, Journalist UI... everywhere. Sentence conjunctions are good for prose, and they make articles interesting to read. They make instructional text more difficult to parse, though. Guiding behavior, not ideas, is the purpose of instructional text. I personally cannot compose sentences without conjunctions, but for messaging users it's important to break-apart conjunctions into stand-alone thoughts/sentences. No commas. Small, simple sentences. Simple words. KISS: Keep It Simple, Stupid.
...and then my jury is out, on how to fit in the "try again later" part. As a total aside from my hesitance to include it at all. I know, I used a comma after "We're sorry," above. A rare exception to keep the tone friendly. Thank you for working this through with me, Erik. And Jen, I trust this in your no-pressure-at-all hands. 😸 |
|
OK how about we go with:
Despite the fact there's no guarantee the organization has written anything about their SecureDrop downtime on their website, it at least provides a pointer for finding other contact methods. There's only so much we can do here, I agree we should only be making very uncontroversial statements since we are speaking from the perspective of the news organization. |
As previously communicated, news organizations must upgrade to Ubuntu 16.04 by April 30, as Ubuntu 14.04 reaches EOL on that date. The Journalist Interface of impacted instances has displayed a warning since March 4, and extensive communications continue through all available channels.
In our previous advisory, we have indicated that we will remove Trusty instances from the SecureDrop directory after April 30, and that “we cannot guarantee that your SecureDrop instance will continue to function after that date."
Running an unsupported operating system on the servers presents an unacceptable risk to sources and newsrooms alike. For this reason, after April 30, news organizations running SecureDrop on Trusty should no longer be able to communicate with sources until they upgrade. The Source Interface should show a neutral message similar to the following (final language TBD):
All source interface functionality should be disabled. The journalist interface should continue to work as before. We should also plan additional comms through all available channels in early April (tracked internally).
User Stories
As a source, I want to have confidence that all my interactions via SecureDrop meet the highest standard of information security, so I face minimal risks of deanonymization by an adversary.
As a news organization, I want my SecureDrop instance to be protected against external compromise at all times, so that existing submissions and correspondence are not exposed to adversaries.
Acceptance Criteria
Given that my SecureDrop servers are running Trusty after April 30
When I connect to the server’s Source Interface
Then I should see a maintenance notice
And all other Source Interface functionality should be disabled
Given that my SecureDrop servers were running Trusty after April 30, but have since been upgraded to Xenial following instructions
When I connect to the server’s Source Interface
Then the Source Interface should operate normally
And no warning message should be displayed
The text was updated successfully, but these errors were encountered: