cross-posted from: https://lemmy.ml/post/45206293

Brazil's authoritarian age verification law became active this month. It won't be implemented by GrapheneOS. Complying would require integrating a mandatory process for each user where a third party service checks government identification and confirms a match using the camera.

It doesn't stop there. It would require keeping data for auditing and providing a token for connecting age verification checks by apps and websites to the data. The law is a privacy disaster and exposes minors to being exploited by leaking their age bracket to apps and websites.

GrapheneOS has no team members or operations in Brazil. São Paulo in Brazil is by far the biggest network hub within South America. Miami is also a major network hub for South America and is currently where our update server is for South America since it's dramatically cheaper.

We have a tiny VPS in São Paulo for our ns1 anycast DNS and a second for our website/network services. It probably isn't an issue and those can be removed if necessary. Santiago could be added for both instead but wouldn't work very well as a replacement for having São Paulo.

There aren't yet devices supporting GrapheneOS directly sold in South America. Brazil in particular has unusually high import duties/taxes which add up to around 100%. This has resulted in us not having a lot of users there but our Motorola partnership will start changing this.

People are going to have their personal info leaked by third party age verification services due to these laws. Children are going to be harmed by apps and websites changing their behavior to exploit them. It isn't going to stop minors finding pornography if they want to find it.

cross-posted from: https://lemmy.ml/post/45059519

Ever seen our AOSP based apps (Phone,Messages,Gallery...) & thought I could make a difference to bring them up?

We're seeking a senior Android engineer to take ownership of the default app suite:

https://grapheneos.org/hiring#android-apps-software-engineer

Code standard is high, vibe coders need not apply.

cross-posted from: https://lemmy.ml/post/45059519

Ever seen our AOSP based apps (Phone,Messages,Gallery...) & thought I could make a difference to bring them up?

We're seeking a senior Android engineer to take ownership of the default app suite:

https://grapheneos.org/hiring#android-apps-software-engineer

Code standard is high, vibe coders need not apply.

cross-posted from: https://lemmy.ml/post/45059519

Ever seen our AOSP based apps (Phone,Messages,Gallery...) & thought I could make a difference to bring them up?

We're seeking a senior Android engineer to take ownership of the default app suite:

https://grapheneos.org/hiring#android-apps-software-engineer

Code standard is high, vibe coders need not apply.

cross-posted from: https://lemmy.ml/post/44781501

GrapheneOS will remain usable by anyone around the world without requiring personal information, identification or an account. GrapheneOS and our services will remain available internationally. If GrapheneOS devices can't be sold in a region due to their regulations, so be it.

cross-posted from: https://lemmy.ml/post/43923687

cross-posted from: https://lemmy.ml/post/43923170

We're happy to announce a long-term partnership with Motorola. We're collaborating on future devices meeting our privacy and security standards with official GrapheneOS support.

https://motorolanews.com/motorola-three-new-b2b-solutions-at-mwc-2026/

cross-posted from: https://lemmy.ml/post/43923170

We're happy to announce a long-term partnership with Motorola. We're collaborating on future devices meeting our privacy and security standards with official GrapheneOS support.

https://motorolanews.com/motorola-three-new-b2b-solutions-at-mwc-2026/

cross-posted from: https://lemmy.ml/post/43923170

We're happy to announce a long-term partnership with Motorola. We're collaborating on future devices meeting our privacy and security standards with official GrapheneOS support.

https://motorolanews.com/motorola-three-new-b2b-solutions-at-mwc-2026/

cross-posted from: https://lemmy.ml/post/9939705

Pixel 4a (5G) and Pixel 5 are end-of-life and shouldn't be used anymore due to lack of security patches for firmware and drivers. We provide extended support for harm reduction.

Tags:

• 2023123000-redfin (Pixel 4a (5G), Pixel 5)
• 2023123000 (Pixel 5a, Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, emulator, generic, other targets

Changes since the 2023121200 release:

• Keyboard: add new implementation of multi-locale spell checking support to fix crashes and other issues
• Sandboxed Google Play compatibility layer: add Android Auto support with the compatibility layer eliminating the need for most of the permissions and a permission menu with 4 toggles for granting the minimal special access required for wired Android Auto, wireless Android Auto, audio routing and phone calls
• Settings: remove confusing mention of Android Auto from Connected devices screen
• exempt non-app system processes from Sensors permission enforcement (fixes some issues including gpsd crashes)
• fix Bluetooth auto-turn-off race condition to avoid crashes
• work around upstream race condition bug in biometric service
• disable support for pre-approving PackageInstaller sessions due to incompatibility with Network permission toggle
• fix several upstream bugs in handling crash reports mainly to improve our user-facing crash reporting system
• use GrapheneOS Widevine provisioning proxy by default
• add settings for changing Widevine provisioning server
• add configuration for setupdesign and setupcompat libraries to improve system UI theme
• kernel (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Generic 5.10): update to latest GKI LTS branch revision including update to 5.10.204
• kernel (Pixel 8, Pixel 8 Pro, Generic 5.15): update to latest GKI LTS branch revision including update to 5.15.142
• kernel (Generic 6.1): initial port of GrapheneOS changes for use with emulator builds
• force disable network ADB in early boot to improve verified boot security (no user-facing change since it's currently disabled by default later in the boot process, but not robustly)
• Vanadium: update to version 120.0.6099.115.0
• Vanadium: update to version 120.0.6099.144.0
• AppCompatConfig: update to version 2
• GmsCompatConfig: update to version 88
• GmsCompatConfig: update to version 89
• GmsCompatConfig: update to version 90
• Auditor: update to version 78

cross-posted from: https://lemmy.ml/post/1784484

Cellebrite and others in their industry use logical extraction to refer to extracting data from a device after unlocking it, enabling developer options (requires PIN/password), enabling ADB and permitting access for the ADB key of the attached device. See https://cellebrite.com/en/glossary/logical-extraction-mobile-forensics/ The baseline doesn't involve exploitation. The next step up is exploitation via ADB to obtain more data than ADB makes available.

Obtaining data from a locked device requires an exploit. If it was unlocked since boot, the OS can access most data of the currently logged in users.

GrapheneOS includes our auto-reboot feature to automatically get data back at rest so that it's not obtainable even if the device is exploited. Can set this to a much lower value than the default 72 hours. 12 hours won't cause inconveniences for most users, but you can go lower.

User profiles that are not currently active have their data at rest. GrapheneOS provides the option to put secondary users back at rest via end session for convenience. Sensitive global system data is stored by the Owner user, which is why you can't log into another user first.

GrapheneOS also provides the option to disable keeping a secondary user active in the background, to force ending the session when switching away from it.

We provide substantial exploit protection features (https://grapheneos.org/features#exploit-protection), and we're working on some major improvements.

For user profiles that are not currently logged in, their data is protected by encryption even if the device is exploited. An attacker needs to brute force the password. If you use a strong random passphrase, they cannot do it. Otherwise, you depend on hardware-based security.

Most Android devices don't have decent hardware-based encryption security. If a typical Android device has the OS exploited, the attacker can trivially bypass any typical PIN/passphrase via brute force. We only support devices defending against this (https://grapheneos.org/faq#encryption).

iPhones, Pixels and certain other Android devices provide hardware-based throttling of unlock attempts via a secure element. We explain how this works at https://grapheneos.org/faq#encryption. This protection depends on security of the secure element, which is quite good for Pixel 6 and later.