Have you ever wondered why #GrapheneOS has a separate PDF viewer?

Well that answer is pretty obvious, it is more secure to have a separate hardened, sandboxed utility designed for that instead of sharing such a responsibility with a much larger app with greater attack surface like a web browser or office suite. It is trivial for some threat actors to deliver weaponized, malicious PDF files to their targets.

If we know all of this, the next step for some may be to wonder "Why is the GrapheneOS PDF viewer secure?", for you, I will explain some of the most important details:

The GrapheneOS PDF Viewer app requires absolutely no user-facing permissions to run, it doesn't ask for any, nor does it need them. Without permissions the app is completely contained in the Android app sandbox and the security access model is far greater.

How the viewer opens a file is through making a false request to Localhost from the WebView and then intercepting that request with a stream of the PDF data. The benefits to this include:

1. We don't needing files access in the WebView (both setAllowFileAccess and setAllowContentAccess are set to false).

2. Allowing us to intercept headers into the request like CSP, Permissions Policy for hardening the sandboxing done via the WebView With CSP, all dynamic and inline CSS and JS is disabled. The only scripts loaded are those used for the viewer itself.

3. In addition to using WebView for PDF Viewer, Vanadium takes the place for the WebView on GrapheneOS, meaning GrapheneOS users take advantage of the exploit protections used in Vanadium.

Even with all of this, the PDF Viewer still has a fair amount of room for improvement when it comes to quality of life features and usability enhancements.

Reply to this note

Please Login to reply.

Discussion

- We don't need*

Worst part about Nostr is no way to fix spelling mistakes that easily. Whoops!

The record is final. No takebacks here. Can't delete tweets that cause an uproar 😁.

If we zap your account does that support the #GrapheneOS project?

This is my personal account and I've been stacking sats prior to being a mod on GrapheneOS on places like SN. This doesn't link to any of their wallets and the project doesn't accept lightning due to security constraints at the moment. Any sats I make involving GrapheneOS support I send back to the project by myself because I imagine people would want that.

I do keep a small amount, but that only goes to sending sats back or to fund something that keeps my work going. Prior to GrapheneOS the sats I made were enough to get a domain name and I do want to create content in the future. It's definitely helped.

The best place for donations is always the GrapheneOS donate page, but I am aware some people will not use anything but Lightning. If I can't send BTC back then I send equivalents in something else. I will post such donations.

nostr:nevent1qqsgskjjlglh965xpj0vxerp3vxf8uhw3pjd92eysljvsujg02na38qpz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzqxqlxdx5d78vv90lztqvnpc9tt5dcqp6rzt8ypd6a6e86s070k0nqvzqqqqqqy6c2jwr

I just wish it didn't suck... Zooming randomly resets, and paging is a nightmare if you have a visual impairment because the paging icons are so thin, when not zooming in on them to switch the page, then moving the zoom area to read the page, things can get lost and a little messy.

But so far, its the only "PDF Viewer" that didnt also have other awkward behaviours.

Why can't there just be a PDF viewer that lets me scroll all pages, two-finger zoom in and out, and ... thats it. :/

Strongly agree on this. The PDF Viewer needs improvements on those fronts, it's just other bigger responsibilities and work on upcoming crucial features takes more of the time.

Would love to see more posts like these.

And sounds like nostr clients need some real time spell checking ;))

Thanks for the explanation andgoofd thinking! In my opinion it still needs GUI improvements such as the interaction when multiple pages, the search ability but...thanks to the team and keep the great work!

For sure. The PDF Viewer has a lot of improvements when it comes to the UI. A lot of time has been focused on more critical responsibilities, such as producing a Duress PIN feature among other things.

I am very happy with GrapheneOS and so thankful for your work.

Just one comment on the PDF Viewer: Swipe to flip pages please! 🙏

I'll forward these suggestions, as a mod I am not in the position to develop apps. Glad to see you are enjoying GrapheneOS! ⚡

In light of a recent high severity vulnerability involving pdf.js, the #GrapheneOS' PDF viewer is not affected.

We use a strict Content-Security-Policy allowlisting the app's static CSS and JavaScript without permitting unsafe-eval or unsafe-inline. It's blocked from using eval or including dynamic JS.

Even if we didn't set a Content Security Policy, the whole point of the app is that it renders a PDF in a sandboxed WebView instance without network, file or content access. It exposes a fairly small subset of the attack surface exposed by a web browser to any web site you visit.

The only data in the sandboxed WebView instance is the PDF which is written into it by the app without giving it access to the file/content. Even if an attacker somehow got JavaScript code execution despite our strict CSP, they couldn't do anything beyond attacking the browser.

The reason we use pdf.js is because it's designed to run efficiently in the browser sandbox. However, unlike opening a website in the browser, we use a restricted environment: no network/file/other access, no dynamic JS or CSS, many features disabled via Permissions Policy, etc.

JavaScript is memory safe but normally has pervasive dynamic code execution via inline JavaScript, dynamically included files and eval. It runs inside a restricted browser sandbox. The browser renderer implementing that sandbox runs inside of the browser's OS level sandbox.

GrapheneOS uses a hardened WebView provided by Vanadium. On Google certified Android OSes, it's provided by Chrome. Either way, our approach is far safer than a C++ PDF library in an OS sandbox (isolatedProcess). It provides 2 extra layers of strong security against most attacks.

Exploiting a vulnerability in the PDF library doesn't really work against our PDF Viewer app since there's an allowlist for the code. In practice, an attacker would need to exploit Chromium's rendering indirectly through pdf.js such as targeting browser font/image rendering.

Android uses isolatedProcess for the official PDF rendering library, which lacks our additional layers of protection and is far easier to exploit. Nearly all Android PDF apps bundle their own C or C++ PDF rendering library and don't bother even using an isolatedProcess sandbox.

Likewise, an update for the PDF viewer had been pushed as soon as the new version was released to have the patched pdf.js version.

Information about the vulnerability: https://github.com/advisories/GHSA-wgrm-67xf-hhpq

nostr:nevent1qqs92ej2czlkwfhstn247g2tvh69nyuwydc7p7ug2ut9desn6ulcs8cppamhxue69uhkummnw3ezumt0d5pzps26tfjesmn6ksf5mm36hpf9fkjut49sfeutfutvs2phrykn25v9qvzqqqqqqycee45h