Skip to content
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

Print from sd-viewer #1137

Open
deeplow opened this issue Jul 9, 2024 · 5 comments
Open

Print from sd-viewer #1137

deeplow opened this issue Jul 9, 2024 · 5 comments
Labels

Comments

@deeplow
Copy link
Contributor

deeplow commented Jul 9, 2024

Description

Some may find confusing the fact that sd-viewer has a print menu, but doesn't actually allow you to print (#278). What it we made it work?

How will this impact SecureDrop/SecureDrop Workstation users?

Improved usability since users could print right away the documents they find worth printing.

How would this affect the SecureDrop Workstation threat model?

If implemented properly (i.e. unidirection communication from sd-viewer to the print vm), it shouldn't add any more risks.
This adds the risk that a malicious document could export / print itself. Since a malicious file could potentially compromize sd-viewer, it follows that it could order its printing.

User Stories

As as journalist I would like to be able to print documents immediately.

@deeplow
Copy link
Contributor Author

deeplow commented Jul 9, 2024

A very primitive implementation of this would be to essentially create a "print to PDF" printer which then sends it off for printing. UX messaging around errors may present some challenges, though.

@rocodes
Copy link
Contributor

rocodes commented Jul 9, 2024

See #278 #564

@rocodes
Copy link
Contributor

rocodes commented Jul 9, 2024

I agree it would be great to print from sd-viewer and/or to have sd-viewer not be a "dead end". Somewhere (maybe in the "print architecture" ticket, or maybe in its own epic) we should figure out a better overall data flow that allows material to flow through the VMs, whether that's a sanitized print rpc that we've talked about occasionally upstream, or an 'export -> dz/sanitize -> print' workflow, or the "briefcase" / one-disp-per-source idea that you had a few years back @deeplow, or what :)

@deeplow
Copy link
Contributor Author

deeplow commented Aug 27, 2024

Just noticed that was also mentioned in the SD Qubes Summit talk from 2022:

@deeplow
Copy link
Contributor Author

deeplow commented Oct 4, 2024

This adds the risk that a malicious document could export / print itself. Since a malicious file could potentially compromize sd-viewer, it follows that it could order its printing.

Added a potential threat with this approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants