web service

[anarcat]

after i have dug quite a bit in the Docker container, i figured i would just go even bolder and consider making this a web service altogether.

it would be ideal for many reasons:

1. it would allow service admins to setup the service for others (which is typically how our organization, Tor, handles such issues)
2. it could still be built on the same backend as the user-facing GUI: a disposable, and well isolated Docker container, which would be started as needed (e.g. through socket activation)
3. it just "feels" right

would you be open to this? i think it would require refactoring the Docker image quite a bit more, but i think it could still be compatible with the current frontend.

Further Evidence / Notes (added by @deeplow)

A user mentioned that they were not very tech-savy and installing programs can be complicated. They suggested having an online Dangerzone version.

[micahflee]

Yes I'd totally be open to this! I'd want to make sure the GUI app and the web service share the same container. And it would probably make sense to put the web service code in a separate repo, like firstlookmedia/dangerzone-web (which I could create).

[anarcat]

Yes I'd totally be open to this! I'd want to make sure the GUI app and the web service share the same container. And it would probably make sense to put the web service code in a separate repo, like firstlookmedia/dangerzone-web (which I could create).

i was thinking the container itself could be a web server. then consumers would talk to it over a socket instead of the commandline + shared volume, which "feels" safer to me for various reasons.

[anarcat]

in other words, the container is the magic service, the GUI app is just a frontend.

[anarcat]

alright, so i ended up doing something like this. it's not really a web service in the traditional sense: it's just a batch script that processes files on a WebDAV server. but with a nextcloud backend, it kind of looks like a web service to users... you share a folder with the dangerzone-bot user, and drop files into it. then the files magically disappear into a dangerzone subfolder, and when processed, appear in a safe folder.

it might not be the best approach, and probably not what you had in mind, but it definitely scratched an itch for us while solving a bunch of issues regarding rate limiting, access control, queuing and storage.

the good stuff lives at https://gitlab.torproject.org/tpo/tpa/dangerzone-webdav-processor/ and has been used in production in one hiring process so far. :)

[deeplow]

If there is to be a web frontend for Dangerzone it could borrow mat2-quasar-frontend implementation (mat2 is avaialble on Tails and Whonix) It is basically the same logic: (demo)

[deeplow]

Having a web service introduces security concerns. It's basically like having a SecureDrop where people drop sensitive files for conversion. If there's ever an exploit to such webservice (e.g. via some vuln in webserver software) the attacker could potentially access any documents sent to the service.

However, if we don't allow document uploads, but rather simply having a place where people could enter a document URL, we'd ensure we'd get public documents only (or at most publicly linkable documents). This would significantly reduce the risk.

[eloquence]

We discussed this a bit per suggestion from @micahflee in our team meeting today. In a nutshell, making it possible for newsrooms to set up a web UI seems appealing as an alternative to the common route of "send a document to a trusted person on the IT/security team who will then have to manually inspect/sanitize it and securely send it back". This would typically be set up in private deployments not accessible to folks not working at said organization.

Some considerations for such a feature (building on the discussion we had today):

• What advice would we give in our documentation for deployment considerations? (E.g., use of SSO proxies, firewall rules, monitoring, and other means to protect a Dangerzone server from being compromised and exfiltrating data to third party hosts; recommendations regarding OS choice, immutable filesystems, use of FDE vs. automatic reboots, etc.)
• What security guidance should be displayed on the web UI itself, to end users uploading documents?
• What records/logging (if any) would be appropriate on such a server?

Generally, I think a feature like this could be a good opportunity to do some threat modeling for the Dangerzone project as a whole, and comparing different deployment strategies.

[harrislapiroff]

Just had a conversation with @almet about this and I wanted to comment here to keep it on our radar, but not work on it yet. I think we shouldn't split our focus too many ways and there's a couple items I think of a prerequisites:

1. Getting Dangerzone to a 1.0 state. We still need to do roadmapping to figure out what we actually want included in 1.0, but I think there's a few features we know we need to land, including On-host pixels to PDF conversion #625 (should be soon) Research/spec for independent container updates #745 (shortly thereafter) and an overhauled UX (Improve Overall UX #117).
2. A threat model for Dangerzone (Develop a formal threat model #938). Creating a web service will require its own security thinking and, as @eloquence flagged last year, we should have clarity on what deployment considerations we'd want to suggest to newsrooms or in the UI itself. A clear threat model will go a long way toward helping with these decisions.