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.

[almet]

Adding a few notes here about a proposed way to go forward with this.

Mobile is known to be a vector for malware infections, and there are multiple cases of Journalists and activists being infected in the wild. Yet, Dangerzone doesn't provide a way for mobile users to do conversions. They have to handle themselves the copy of the document to a desktop computer and do the conversion there.

Shipping a mobile application to convert unsafe docs into safe ones would be interesting, but technical limitations apply, making it currently hard to run containers on mobile — there are reported ways to do that, but it's technically involved — and so not really suitable for us in the foreseeable future.

One other way to provide conversions on mobile would be to have a sort of web service, but that seem unpractical as well as a) users would have to trust us with their data and b) that would make the host a target for an attacker.

Web-companion mode

With these limitations in mind, one other way would be for users to "pair" their devices with a "server" companion, akin to how WhatsApp used to work at some point, where the connection was proxied through the phone to access the data stored there.

In this scenario, Dangerzone would be split into two parts:

• The server part, responsible for doing the conversion, and running the containers.
• The client part, responsible to display an interface to the users.

The pairing of the devices could happen using QR codes or some specifically crafted links which could contain a set of cryptographic keys.

The users, or trusted third parties would host the server part (think about newsrooms).

Required changes on the client

At the time of writing (January 2025), dangerzone code requires a few changes for this to happen:

• Move from filenames to file-like objects.

  Right now a filename is required when doing the conversion. Instead, we could change the exposed API to require a file-like object, allowing for the files to never be stored on the server.

Outcomes

• It should then be possible to split the client and server apart, and install one without the other.
• The dependency to Docker could be relaxed, which would make it easier to install for some specific targets like Windows and macOS.