KindnessInfinity

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/1899649

Hello,

Below are linked communities I am moderating, but can't remove inactive/deleted moderators from:

!thehatedone@lemmy.ml

!aosp@lemmy.ml

!androidapps@lemmy.ml

!androidofficial@lemmy.ml

Users along with their posts that are deleted/inactive that neither I or the group owner can't seemingly remove from moderation are:

u/TheSilencedOne can't find posts or comments on ANY of the communities I moderate and that list this account as moderator.

u/Lunacy post https://lemmy.ml/post/85921

u/Zanthed post https://lemmy.ml/post/85569

u/lunacy post https://lemmy.ml/post/86672

u/zenthed post https://lemmy.ml/post/100140

Please remove u/Zanthed, u/TheSilencedOne and u/lunacy from moderation on all above listed communities.

Thank you for your time.

If anybody may please help me or community owner with removing these accounts, it'd be greatly appreciated. Thank you

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.