-
Notifications
You must be signed in to change notification settings - Fork 690
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve SecureDrop loading experience over Tor Hidden Services #1152
Comments
I started working on this, but ran into an issue with the development cycle and our existing set of automated development environments. Rather than work around it, I think this is an instructive use case that could help us improve our development environments and automation. Essentially, the problem is:
The @conorsch What do you think the best next move is here? |
@garrettr Ah, a subject near and dear to my heart. The lack of automated building as part of the The solution is to trigger deb package builds during the staging deployment, and use that artifact during provisioning. I've tabled the Let me take a look at providing a wrapper playbook with the current state of the ansible config that would essentially chain the build-deb-package-then-provision-staging workflow. That should be shippable with a far less burdensome review process, and provide you with a less hair-pulling process to test bleeding-edge code over Tor. |
@conorsch The alternative is to make resolving this issue a dependency of the Ansible reorg, which I'm totally fine with. There's a lot of other stuff I could be working on, I just picked this one up since I spent so much time thinking about the issue while filing it and it seemed fairly straightforward. |
@garrettr Upon closer inspection, there's a more direct path that works with the current config. Try to reproduce and let me know how it treats you.
That's it. The build role will run first, and dump out new packages. Then the staging playbook will kick in, and since you've overridden the default of "don't install local packages", the local packages will be used during the staging provisioning run. The The current implementation of the |
Some rough benchmarking info: destroying and recreating |
Tried to reproduce. I got an error:
I will copy the ossec debs (which are built by an Ansible role currently maintained in the separate ossec repo) to |
Discussion of the ossec debs is over in the ossec repo, with a proposed solution to the clunky error messages. |
Changes to the |
Is using mod_pagespeed an option? I haven't used it yet, but we're considering using the Nginx flavor at work for something. |
Closing; the behavior described here no longer occurs with current versions of SecureDrop, thanks to improvements that have since been made to templates and styling, and likely also in part due to upstream changes in Firefox ESR. |
In production, all of SecureDrop's web interfaces (the Source Interface and the Document Interface) are only available as Tor Hidden Services, which have extremely restricted bandwidth. In addition, SecureDrop intentionally avoids caching any resources in the client's browser to avoid potential forensic infoleaks.
These qualities combine to make the SecureDrop web interface feel slow and glitchy, particularly when used over an especially slow hidden service connection:
Specific Issues to Fix
Potential Resolutions
The text was updated successfully, but these errors were encountered: