freedomofpress
Dangerzone Web Mode
What is the feature you think should be a good addition to Dangerzone?
I would love to run this on a server so that my coworkers are able to safely view files and/or setup automation in the future to do this to all documents sent inbound. However asking them to install it seems strange since this feels a little too technical for them with docker. Wondering if there are plans, or if your open to, to having a way to run this in the web.
Additional context
I do web development focused in security and would love to help aswell, just want to make sure I'm thinking about this right and that if this is the right place to do it?
You're definitely thinking about this right, and it's something that we'd really like as well, because it opens lots of new options; support for mobile users, modernizing our Qt GUI, etc. There have been other alternatives on the table, of course, e.g., making Dangerzone available via a Signal chatbot, but the web server idea always resurfaces from time to time.
In any case, I can't say when we will be able to start working on this front, since we are currently focusing on providing timely container updates to our users, and not relying on an external container runtime (i.e., Docker Desktop). But I do agree that it is a much coveted feature.
You're definitely thinking about this right, and it's something that we'd really like as well, because it opens lots of new options; support for mobile users, modernizing our Qt GUI, etc. There have been other alternatives on the table, of course, e.g., making Dangerzone available via a Signal chatbot, but the web server idea always resurfaces from time to time.
In any case, I can't say when we will be able to start working on this front, since we are currently focusing on providing timely container updates to our users, and not relying on an external container runtime (i.e., Docker Desktop). But I do agree that it is a much coveted feature.
Do you think it would be worth me trying to get a PoC up and running for it? I've been working on websites and docker for a decent amount of time if that sounds like something people want
Hey, thanks for opening a comment. As @apyrgio mentioned, it's something that some of us really want to do in the future, as for instance it can enable mobile use cases. However, we have concerns about how this should be done, as running DZ as a web server could be very valuable to attackers (it would be an easy target where to find documents, or where to collect them), so we would need to be extra careful when handling these (to be sure they don't hit disk), and need to take a set of security measures.
I'm very interested in the subject myself, and we've been discussing that already in #110 (which I believe is a duplicate of your issue); To give your some more context, currently it's not something we're planning to do in the near future because it requires us to have a fleshed-out threat model (we're working on it) and because we're planning to do some other UX-related tasks first (also we're currently implementing some quite demanding features and don't want to be spread too thin)
Do you think it would be worth me trying to get a PoC up and running for it? I've been working on websites and docker for a decent amount of time if that sounds like something people want
I started doing a PoC myself this winter and I actually think it's not required to have one. I've identified some roadblocks and I believe it would be nice to decide on the architecture and UX before going full-on on the dev (and of course, have a discussion about the implementation plan with security-minded folks).
But I want to thank you for proposing your energy here, and want to find a way to keep the momentum, so let's also take the opportunity of your message as a way to "brush the garden", and maybe define the items that needs to be done before an actual implementation.
I'll put that in the agenda of our next team meeting (should happen in a week), and will get back at you with our general thinking on the matter.
Cheers!
(I'm letting this issue open, if you want to react on that, and as a way to get back to you, but will close it later on as I think it's a dupe of #110)
Hi @adamjsturge.
We've had a good chat with the team last Thursday about this, and the main take-away is that we would be glad to have a proof-of-concept, if you still want to work on something.
We've split the requirements into three parts: a) hard requirements, b) soft requirements and c) not requirements (should not be done now):
Hard requirements
- No file data must remain on the server: the process should not leave traces on the server about the files which are transiting. As a result, the server should not (be able to) return any info about past documents;
- The server should never attempt to parse parts of the file
- The server should have a REST API: It should expose an HTTP API first, and eventually a web frontend to it, but they should be split in two separated components (this might prove useful in the future, if we ever decide to switch to use the REST API for the GUI for instance)
- This API should be documented
- The site should have a robust CSP header
- If the browser requires to store some state, it should not contain file names or contents
- It should be optional. People shouldn't be forced to use it or install it
- The backend should be written in python (the whole project is written in python, which will make it easier to maintain in the long run).
- Using tools like Flask or FastAPI is preferred to full-fledged Django apps and other frameworks.
- The dependencies should be kept to the minimum.
- The resulting tool should be easy to package and distribute on the supported platforms (so, no exotic deps)
Soft requirements & ideas
These are things we would like to have, but it's of course acceptable to do things differently.
- The server should use Dangerzone's Python interface, and not the CLI
- The UI should support progress reports
- The frontend should contain the less JS as possible. Using Web Components is advised ;
Not needed right now / Ideas
Here is a section with ideas that require some more thoughts, that we want to share with you, but definitely aren't stuff we need for a PoC work.
- It should be possible to have a way to link devices, to potentially enable a "web companion" mode, for instance for cell phones, in order to convert the documents there ;
- The server and client could exchange keys and encrypt the inbound and outbound documents
- If there is a queue to be had, ideally the documents should be sent to this queue at the last minute, to minimize the attack surface (the amount of documents available in memory on the server).
A word of caution
We want to stress out that the servers shouldn't be "open servers" for anybody to use, but we'd rather want to have services operated by the groups that will benefit them (think newsrooms).
If you have any question, and/or if you need assistance, need to change some APIs on the dangerzone side or just want to schedule a discussion, please let us know. @apyrgio or myself will be glad to help.
Thanks for helping Dangerzone move forward on this idea of a web component to it, I hope that this proof of concept work will be useful to find areas where the API should be improved, and eventually become a full-fledged thing (but of course, we make no promises here, and the scope of the work is one of a PoC).
