If the threat model is the app spying on you, open source apps like Okular are great.
For Android readers sending your data to the vendor, you should cut the internet connectivity of that app in the app’s settings OS side.
If the threat model is malicious PDFs: There’s not too many hardened PDF editors, and what journalists who open untrusted PDFs all the time do, is they use Qubes OS that allows opening PDFs in disposable VMs. This contains any infection to a temporary sandbox and when the PDF is closed, the OS gets destroyed.
Since it hasn’t been mentioned here yet: A few months ago, a handful of features were added to Firefox’s inbuilt PDF editor. While I haven’t used it personally yet, I think it should now cover all use cases most people generally have and is worth checking out, especially if you don’t want to install a separate tool just for PDFs.
Yes, it works very well and the editing capabilities covers 90% of usual needs.
It’s my main pdf viewer now.
It is sandboxed but you probably want to disable javascript in the pdf viewer in about:config and switching to false pdfjs.enableScripting.
@CarefulMouse Disconnecting first is a fair check, but it only proves the page can run offline. It doesn’t tell you what would have gone out while you were connected.
Open DevTools, watch the Network tab, then add your file. A tool doing the work in JS or wasm won’t send a single request at that point. If one goes out carrying the file, that’s your answer.
Also, “encrypted storage” only makes sense if they’re storing files somewhere.
Two different passwords can sit on a PDF. The user password is real encryption. The owner password is only permission bits the reader is expected to respect, and that is the one most “remove password” tools actually strip. On iOS this bites harder, because PDFKit’s dataRepresentation export writes the original encryption straight back out.