GrapheneOS

GrapheneOS, 16 hours ago

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.

GrapheneOS, 16 hours ago

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.

GrapheneOS, 16 hours ago

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.

GrapheneOS, 16 hours ago

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, 16 hours ago

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.

GrapheneOS, 16 hours ago

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.

GrapheneOS, 16 hours ago

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.

GrapheneOS, 22 hours ago

@5e336907a3dda5cd58f11d162d8a4c@mostr.pub

Thanks for the support!

There are a lot more great features on the way including App Communication Scopes, 2-factor fingerprint unlock, duress PIN/password and much more.

GrapheneOS, 22 hours ago

@tom @dajb Compatibility with Android apps is much different since GrapheneOS provides our sandboxed Google Play compatibility layer:

https://grapheneos.org/usage#sandboxed-google-play

Can run the vast majority of Play Store apps on GrapheneOS, but not CalyxOS with the much more limited microG approach. This doesn't change that an app requiring a Google certified OS via Play Integrity won't work though, which this app is in the process of adopting.

They need to be convinced to follow https://grapheneos.org/articles/attestation-compatibility-guide.

GrapheneOS, 22 hours ago

@tom @dajb https://eylenburg.github.io/android_comparison.htm is a third party comparison between different alternate mobile operating systems. It could include many more privacy/security features but it's a good starting point.

https://privsec.dev/posts/android/choosing-your-android-based-operating-system/ is an article with more long form comparisons between OSes.

GrapheneOS, 22 hours ago

@johnmclear They've chosen to start using Play Integrity API to ban using an OS that's not approved by Google. It's a fake security feature since approval by Google has no real connection to security. It means they permit an OS without security patches for several years but not GrapheneOS which provides much better security. Please contact them via email or a support ticket and make sure to send them https://grapheneos.org/articles/attestation-compatibility-guide explaining how to use hardware attestation to verify it's GrapheneOS.

GrapheneOS, 22 hours ago

@dajb @shortwavesurfer2009 It would also defeat the purpose of what they're trying to do if they provided the same features via online banking. They likely have features specific to the app such as depositing cheques. They wrongly believe that they're improving security by enforcing having a Google certified OS via the Play Integrity API. They need to be convinced to implement https://grapheneos.org/articles/attestation-compatibility-guide which allows them to keep doing the checks they're doing while permitting GrapheneOS too.

GrapheneOS, 22 hours ago

@dajb @shortwavesurfer2009 It would be better if apps stopped doing meaningless client-side security checks like these unless they actually have a reason to do it and are doing it properly via the hardware attestation API which offers the ability to support an alternate OS via permitting the yellow verified boot state with a whitelist of their keys. Play Integrity API only supports an OS/device approved by Google with no way to support hardware or operating systems they haven't approved.

GrapheneOS, 22 hours ago

@tom @dajb It's not about that but rather what we're doing is almost entirely different from other alternate operating systems presented as being private and/or secure. In many cases, we're doing the opposite of what they're doing. The goal isn't at all shaming you but rather we don't want to be grouped in with operating systems rolling back security especially since we need to convince apps that are checking for alternate operating systems and forbidding them to support https://grapheneos.org/articles/attestation-compatibility-guide.

GrapheneOS, 22 hours ago

@Aakerbeere @scotty86 @ip6li Using GrapheneOS doesn't involve a rooted device. It preserves the standard security model and is intended to be used with the bootloader locked. It substantially improves security rather than reducing it like other alternate operating systems.

The user replying recommending it is incorrect about blocking domains while using a VPN which is fully supported by using an app supporting both. It's the correct way to do it, unlike AFWall which greatly harms security.

GrapheneOS, 22 hours ago

@scotty86 @ip6li @Aakerbeere AFWall substantially rolls back security and is the wrong approach to filtering traffic while using a VPN. The correct approach is using an app supporting both filtering traffic and using a VPN. Using a hosts file is extremely inefficient and doesn't work correct. Filtering DNS packets with a firewall is also a wrong approach and won't do anything about DNS-over-TLS or DNS-over-HTTPS if you're using Private DNS (not normally useful if you're using an actual VPN).

GrapheneOS, 22 hours ago

@scotty86 @Aakerbeere @ip6li @kuketzblog AFWall greatly reduces your security. Giving root access to a massive portion of the OS and a problematic app greatly increasing attack surface is in no way required to filter traffic including filtering DNS requests. You should read our FAQ sections on this since despite not covering a lot, this is one of the topics that's explained there. There are VPN apps supporting both filtering traffic and using an actual VPN. It's the correct, secure approach.

GrapheneOS, 22 hours ago

@Aakerbeere @scotty86 @ip6li @kuketzblog It's very easy to install GrapheneOS via https://grapheneos.org/install/web and devices can be purchased with GrapheneOS installed. No technical understanding is needed to follow the simple web installer instructions as demonstrated by many completely non-technical people from children to seniors installing it successfully. People can get help with installing it with 24/7 real time support via our official chat room, or our forum if they prefer it.

GrapheneOS, 22 hours ago

@Aakerbeere @scotty86 @ip6li @kuketzblog GrapheneOS only uses GrapheneOS services by default including secure network time via HTTPS. Please read https://grapheneos.org/faq#default-connections.

Whole point of GrapheneOS is that it substantially improves both privacy and security while still being able to use mainstream apps and websites. Many of the privacy features it provides such as Storage Scopes, Contact Scopes and the Sensors toggle are for preserving your privacy from apps while still being able to use them.

GrapheneOS, 22 hours ago

@ip6li @Aakerbeere @scotty86 @kuketzblog Can directly do both filtering and using a VPN at the same time via a VPN app supporting it. There are VPN service apps supporting doing both at once. Filtering traffic is not a fundamental improvement in privacy. It does not prevent apps/sites sending data anywhere, just not directly to certain servers not providing useful functionality to users. GrapheneOS provides privacy and security on a much more fundamental level rather than filtering some things.

GrapheneOS, 22 hours ago

@scotty86 @Aakerbeere @ip6li @kuketzblog Pixels are the most secure smartphones available and are the only secure devices providing first class alternate OS support. Our hardware security and other requirements are listed at https://grapheneos.org/faq#future-devices. It's not a limitation of GrapheneOS that it only supports Pixels but rather a limitation of non-Pixel hardware which is far from meeting these requirements. It's a choice by the project to only support secure hardware meetings reasonable standards.

GrapheneOS, 11 hours ago

@christiee GrapheneOS doesn't consider cellular networks trusted and we strongly recommend using encrypted messaging apps for calls and texts.

5G upgraded the cryptography, etc. but is also a lot more complex. The complexity is only relevant in terms of attacks surface. Not really clear what you're asking specifically.

If you're wondering why we don't have a 5G-only mode yet, it's simply because it wasn't very practical for most people until recently and we didn't add another mode yet.

GrapheneOS, 11 hours ago

@christiee Not clear why you're sharing this screenshot. What are you showing with this?