Next release of #GrapheneOS will enable the new Desktop Mode on all devices rather than just the Pixel Tablet.

They should still need the feature. Forensic experts would be trained in device repair and just replace the port, so it should disable itself even when the port is replaced. It would increase the time before an extraction attempt could be performed though.

This is a GrapheneOS feature by default, 18 hours but configurable to 30 minutes of inactivity. iOS implemented it too but it's done in 3 days of no unlock. The Shortcuts app could be useful for this as you can assign device restarts to a trigger. A more primitive shortcut could be to assign a reboot when the clock hits a certain hour such as when you're asleep.

Stronger USB port security features would help, I don't see why Apple couldn't copy what GrapheneOS does with disabling Pixels' USB-C port at a hardware level when they create both the phone and OS.

Yes. If the device is unlocked successfully via brute force then it's considered an unlocked device extraction. Cellebrite call hot phones that are locked 'AFU' and hot phones that are unlocked / brute forced successfully as 'Unlocked'. Older Cellebrite docs we published used to call their AFU iOS capabilities Instant Password Retrieval (IPR) but they stopped doing that for some reason.

AFU exploits are to access and extract data without unlocking the device or to bypass the unlock mechanism entirely. Since data isnt encrypted/at rest when AFU they can obtain almost all of the data (except conditional circumstances like data of other Android user profiles or the Mail inbox on iOS) if an exploit is available.

"BFU Yes" in their docs means accessing data encrypted by the device rather than user credentials in a BFU state. For Android it's some OS configuration and APKs of installed apps. iOS provides far more information.

Yes. If the device is unlocked successfully via brute force then it's considered an unlocked device extraction. Cellebrite call hot phones that are locked 'AFU' and hot phones that are unlocked / brute forced successfully as 'Unlocked'. Older Cellebrite docs we published used to call their AFU iOS capabilities Instant Password Retrieval (IPR) but they stopped doing that for some reason.

AFU exploits are to access and extract data without unlocking the device or to bypass the unlock mechanism entirely. Since data isnt encrypted/at rest when AFU they can obtain almost all of the data (except conditional circumstances like data of other Android user profiles or the Mail inbox on iOS) if an exploit is available.

"BFU Yes" in their docs means accessing data encrypted by the device rather than user credentials in a BFU state. For Android it's some OS configuration and APKs of installed apps. iOS provides far more information.

No and yes. It can't be done directly through the OS and requires convoluted processes such as debug features and tampering with non-persistent state but it provides little overall value that avoids the solution of dealing with a hostile network like it which is not using that network at all. High risk users should just stick to WiFi and not use a SIM. Airplane mode prevents tracking from cellular by disabling the cellular radio. Such identifers usually aren't visible to apps in the OS unless they have READ_PRIVILEGED_PHONE_STATE, so system apps. The default SMS app is a special case that's given access to the IMEI, which is normally the GrapheneOS fork of the AOSP Messaging app unless users explicitly change it to another app at their own discretion.

We had been asked about it and clarified back when old Snapdragon Pixels could do it. Exynos Pixels could, but it's a no at this stage and had been for a long time It's nothing like WiFi MAC address randomisation.

Changing IMEI wouldn't prevent tracking via cellular since there are other identifiers specific to radios and also extensive fingerprinting possibilities. Choosing a random IMEI while everything else being the same as before would make you almost entirely unique as a starting point. It will only hide one commonly used ID rather than making the device not uniquely identifiable.

Carriers often detect device model via IMEI and multiple other ways as part of their standard operating procedure. They change how things work based on the detected capabilities but also hard-wired quirks for device models, etc. Devices send a lot of info on capabilities or features they support. The general type of radio/device is extremely obvious to the network since a bunch of capabilities, configuration, etc. vary and are directly reported to the network. We try to match stock Pixel OS configuration but it's clear it's a Pixel based on network behavior and not just an arbitrary number.

Identifying yourself to the network is what a SIM implements so you inherently get identified as a specific subscriber based on that too. You could change SIMs often but that's costly and doesn't solve the above problem. The radio is also supposed to send a unique identifier and will often send other identifiers, including but not limited to EID when using eSIM.

Since IMEI is typically configurable by OEMs building the phone and often has a debug feature for changing it, it can end up being possible to change it. It's a mistake and typically comes along with vulnerabilities. Reporting upstream could come with rewards but we're not looking into it. If upstream patches it, its no good for us then...

GrapheneOS only generally reports to Google if the vulnerability is major, exploited in the wild and/or their input to patch is required to protect the devices we support. Last major example of when we did this was for vulnerabilities exploited by a forensics firm selling a password brute force exclusively for the stock OS. While not affecting GrapheneOS the response and firmware changes helped us greatly in implementing duress password.

I also haven't counted RF fingerprinting (affects other radios too) or tracking miscellaneous artefacts like mobile data web traffic (conditional) or direct connection to the provider's IPsec tunnel for WiFi. RF fingerprinting two of the same mobile devices is a common academic project and you can check them out online.

Uninformed users would be fed false hope and act in ways they shouldn't with the feature which could endanger them. There is no legal restriction holding the project back, it's the above reasons.

We plan to provide more configuration for controlling Wi-Fi calling/texting where users can entirely toggle off the IPsec tunnel it uses while still using the SIM. It's not one of our top priorities since disabling the SIM is already available as a standard option and does that.

Are you using a different keyboard app? If so, which?

Are you using a different keyboard app? If so, which?

3 foods you should never eat:

- Foods you don’t enjoy

- Foods that make you feel like crap

- Foods that aren’t worth the calories

That’s it.

#health #healthstr #food #foodstr